home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 8_2_10.tro < prev    next >
Text File  |  1991-12-22  |  70KB  |  2,600 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright (~c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v'|.5i'
  22. .sp 2P
  23. .LP
  24. \fBRecommendation\ X.29\fR 
  25. .RT
  26. .sp 2P
  27. .ce 1000
  28. \fBPROCEDURES\ FOR\ THE\ EXCHANGE\ OF\ CONTROL\ INFORMATION\fR 
  29. .EF '%    Fascicle\ VIII.2\ \(em\ Rec.\ X.29''
  30. .OF '''Fascicle\ VIII.2\ \(em\ Rec.\ X.29    %'
  31. .ce 0
  32. .ce 1000
  33. \fBAND\ USER\ DATA\ BETWEEN\ A\ PACKET\fR 
  34. .ce 0
  35. .ce 1000
  36. \fBASSEMBLY/DISASSEMBLY\ (PAD)\ FACILITY\fR 
  37. .ce 0
  38. .sp 1P
  39. .ce 1000
  40. \fBAND\ A\ PACKET\ MODE\ DTE\ OR\ ANOTHER\ PAD\fR 
  41. .ce 0
  42. .sp 1P
  43. .ce 1000
  44. \fI(provisional, Geneva, 1977; amended, Geneva, 1980,\fR 
  45. .sp 9p
  46. .RT
  47. .ce 0
  48. .sp 1P
  49. .ce 1000
  50. \fIMalaga\(hyTorremolinos, 1984 and Melbourne, 1988)\fR 
  51. .ce 0
  52. .sp 1P
  53. .LP
  54.     \fBPreface\fR 
  55. .sp 1P
  56. .RT
  57. .PP
  58. The establishment in various countries of public data networks
  59. providing packet\(hyswitched data transmission services creates a need 
  60. to produce standards to facilitate international interworking. 
  61. .RT
  62. .sp 2P
  63. .LP
  64.     The\ CCITT,
  65. .sp 1P
  66. .RT
  67. .sp 1P
  68. .LP
  69. \fIconsidering\fR 
  70. .sp 9p
  71. .RT
  72. .PP
  73. (a)
  74. that Recommendations X.1 and X.2 define the user classes of service and 
  75. facilities in a public data network, and Recommendation\ X.96 
  76. defines call progress signals;
  77. .PP
  78. (b)
  79. that Recommendation X.3 defines the PAD in a public data network;
  80. .PP
  81. (c)
  82. that Recommendation X.28 defines the DTE/DCE interface for a start\(hystop 
  83. mode DTE accessing the PAD in a public data 
  84. network;
  85. .PP
  86. (d)
  87. that Recommendation X.25 defines the interface between the DTE and the 
  88. DCE for DTEs operating in the packet mode in public data 
  89. networks;
  90. .PP
  91. (e)
  92. the need to allow interworking between a packet
  93. mode DTE and a non\(hypacket mode DTE in the packet\(hyswitched transmission
  94. service;
  95. .PP
  96. (f
  97. )
  98. the urgent need to allow interworking between a
  99. start\(hystop mode DTE in a public switched telephone network, public switched
  100. data network or a leased line and a packet mode DTE using the virtual call
  101. facility of the packet\(hyswitched transmission service;
  102. .PP
  103. (g)
  104. the need to allow interworking between PADs;
  105. .PP
  106. (h)
  107. that the packet mode DTE shall not be obliged to use the control procedures 
  108. for PAD functions, but that some packet mode DTEs may wish to control specific 
  109. functions of the PAD, 
  110. .sp 1P
  111. .LP
  112. \fIunanimously recommends that\fR 
  113. .sp 9p
  114. .RT
  115. .PP
  116. (1)
  117. the Recommendation X.29 procedures shall apply to the
  118. Recommendation\ X.25 interface between the DCE and the packet mode DTE;
  119. .PP
  120. (2)
  121. the Recommendation X.29 procedures may be applied for
  122. interworking between PADs;
  123. .PP
  124. (3)
  125. the procedures be as specified below in \(sc\ 1 \fIProcedures\fR \fIfor 
  126. the exchange of PAD control information and user data\fR ; 
  127. .PP
  128. (4)\fR the manner in which user data is transferred be as
  129. specified below in \(sc\ 2 \fIUser data transfer\fR ;
  130. .PP
  131. (5)
  132. the procedures for the control of the PAD via PAD
  133. messages be as specified below in \(sc\ 3 \fIProcedures for the use of PAD\fR 
  134. \fImessages\fR ;
  135. .PP
  136. (6)
  137. the formats of the data fields which are transferable on a virtual call 
  138. be as specified below in \(sc\ 4 \fIFormats\fR . 
  139. .PP
  140. \fINote\ 1\fR \ \(em\ For ease of understanding, this Recommendation refers 
  141. to specific packet types and procedures of Recommendation\ X.25. When PAD 
  142. to PAD interworking is considered within a national network these packet 
  143. types or 
  144. procedures may have a different form from those used in Recommendation\ X.25
  145. but will have the same operational meaning.
  146. .bp
  147. .PP
  148. \fINote\ 2\fR \ \(em\ The following items are for further study:
  149. .RT
  150. .LP
  151.     \(em
  152.     the use of the permanent virtual circuit service;
  153. .LP
  154.     \(em
  155.     interworking between DTEs having interfaces to different data
  156. transmission services;
  157. .LP
  158.     \(em
  159.     operation of non\(hypacket mode DTEs in other than start\(hystop
  160. mode.
  161. .sp 2P
  162. .LP
  163. \fB1\fR     \fBProcedures for the exchange of PAD control information
  164. and user data\fR 
  165. .sp 1P
  166. .RT
  167. .PP
  168. 1.1
  169. The exchange of control information and user data between a PAD and a packet 
  170. mode DTE or between PADs is performed by using user data fields 
  171. defined in Recommendation\ X.25.
  172. .sp 9p
  173. .RT
  174. .PP
  175. 1.2
  176. Annex A describes some of the characteristics of virtual calls
  177. as defined in Recommendation\ X.25, as related to the PAD representation of
  178. a start\(hystop mode DTE to a packet mode DTE. The characteristics described in
  179. Annex\ A also apply for interworking between PADs.
  180. .sp 1P
  181. .LP
  182. 1.3
  183.     \fICall user data\fR 
  184. .sp 9p
  185. .RT
  186. .PP
  187. The 
  188. call user data field
  189. of \fIincoming call\fR \| or \fIcall\fR 
  190. \fIrequest\fR \| packets to or from the packet mode DTE or the PAD is comprised 
  191. of 
  192. two fields:
  193. .RT
  194. .LP
  195.     a)
  196.     the 
  197. protocol identifier field
  198. , and
  199. .LP
  200.     b)
  201.     the 
  202. call data field
  203. .
  204. .PP
  205. The protocol identifier field is used for protocol identification purposes 
  206. and the call data field contains user data. 
  207. .PP
  208. A \fIcall request\fR \| packet received by the PAD, containing no call 
  209. user data field, will be accepted by the PAD. 
  210. .PP
  211. If a call data field is present, the PAD will send it, unchanged, to the 
  212. start\(hystop mode DTE, using the call data block of the \fIincoming call 
  213. PAD\fR \fIservice\fR signal (see \(sc\ 3.5.22, Recommendation\ X.28). 
  214. .RT
  215. .sp 2P
  216. .LP
  217. 1.4
  218.     \fIUser sequences\fR 
  219. .sp 1P
  220. .RT
  221. .PP
  222. 1.4.1
  223. User sequences are used to exchange user data between the PAD and the packet 
  224. mode DTE or a PAD. 
  225. .sp 9p
  226. .RT
  227. .PP
  228. 1.4.2
  229. User sequences are conveyed in the user data fields of complete
  230. packet sequences with Q\ =\ 0, and in both directions on a virtual call. (See
  231. Recommendation\ X.25.)
  232. .PP
  233. 1.4.3
  234. There will be only one user sequence in a complete packet
  235. sequence.
  236. .PP
  237. 1.4.4
  238. The PAD will transmit all \fIdata\fR \| packets with the D bit set to
  239. 0.
  240. .PP
  241. On reception of a \fIdata\fR \| packet with the D bit set to 1, the PAD 
  242. will transmit the corresponding acknowledgement as soon as possible. 
  243. .PP
  244. If the PAD does not support the D bit procedure, the PAD may reset the 
  245. virtual call. 
  246. .PP
  247. As no error correction procedure is in place from the PAD to the
  248. start\(hystop mode DTE, no guarantee of delivery can be implied from the
  249. acknowledgement.
  250. .RT
  251. .sp 2P
  252. .LP
  253. 1.5
  254.     \fIPAD messages\fR 
  255. .sp 1P
  256. .RT
  257. .PP
  258. 1.5.1
  259. \fIPAD\fR \| messages are used to exchange control information
  260. between the PAD and the packet mode DTE (or remote PAD). A \fIPAD\fR message
  261. consists of a 
  262. control identifier field
  263. and a 
  264. message code field
  265. possibly followed by a 
  266. parameter field
  267. (see \(sc\ 4.4 below).
  268. .sp 9p
  269. .RT
  270. .PP
  271. 1.5.2
  272. \fIPAD\fR \| messages are conveyed in the user data fields of complete 
  273. packet sequences with Q\ =\ 1 and in both directions on a virtual call. 
  274. (See Recommendation\ X.25.)
  275. .PP
  276. 1.5.3
  277. There will be only one \fIPAD\fR \| message in a complete packet
  278. sequence.
  279. .PP
  280. 1.5.4
  281. The PAD will take into consideration a \fIPAD\fR \| message only when it 
  282. has been completely received. 
  283. .PP
  284. 1.5.5
  285. In the case where a parameter reference (see \(sc\ 3 below) appears
  286. more than once in a \fIPAD\fR \| message, only the last appearance is taken 
  287. into 
  288. account.
  289. .bp
  290. .PP
  291. 1.5.6
  292. The PAD will transmit all \fIdata\fR \| packets with the D bit set
  293. to 0.
  294. .PP
  295. On reception of a \fIdata\fR \| packet with both the Q bit and the D bit 
  296. set to 1, the PAD will transmit the corresponding acknowledgement as soon 
  297. as 
  298. possible.
  299. .PP
  300. If the PAD does not support the D bit procedure, the PAD may reset the 
  301. virtual call. 
  302. .RT
  303. .sp 2P
  304. .LP
  305. \fB2\fR     \fBUser data transfer\fR 
  306. .sp 1P
  307. .RT
  308. .PP
  309. 2.1
  310. \fIData\fR \| packets will be forwarded by the PAD when a \fIset\fR ,
  311. \fIread\fR , or \fIset and read PAD\fR \| message is received, or under 
  312. any of the other data forwarding conditions provided by the PAD (see Recommendation\ 
  313. X.28, 
  314. \(sc\ 4.4).
  315. .sp 9p
  316. .RT
  317. .PP
  318. 2.2
  319. The occurrence of a data forwarding condition will not cause the PAD to 
  320. transmit empty data packets. 
  321. .sp 2P
  322. .LP
  323. \fB3\fR     \fBProcedures for the use of PAD messages\fR 
  324. .sp 1P
  325. .RT
  326. .sp 1P
  327. .LP
  328. 3.1
  329.     \fIProcedures for reading, setting, and reading and setting of PAD\fR 
  330. \fIparameters\fR \v'3p'
  331. .sp 9p
  332. .RT
  333. .PP
  334. 3.1.1
  335. The current values of PAD parameters may be changed and read
  336. by transmitting to the PAD a \fIset\fR , \fIread\fR , or \fIset and read 
  337. PAD\fR 
  338. message.
  339. .PP
  340. 3.1.2
  341. When the PAD receives a \fIset\fR , \fIread\fR \| or \fIset and read PAD\fR \|
  342. message, any data previously received will be delivered to the start\(hystop
  343. mode DTE before taking action on the \fIPAD\fR message. The PAD will also 
  344. consider the arrival of such a \fIPAD\fR message as a data forwarding condition. 
  345. .PP
  346. 3.1.3
  347. The PAD will respond to a valid \fIread\fR \| or \fIset and read PAD\fR \|
  348. message by transmitting a \fIparameter indication PAD\fR message. This 
  349. \fIPAD\fR 
  350. message will have a parameter field containing a list of parameter references 
  351. and current values (after any necessary modification) of the PAD parameters 
  352. to which the received \fIPAD\fR message referred. 
  353. .PP
  354. 3.1.4
  355. The PAD will not return a \fIparameter indication PAD\fR \| message in 
  356. response to a valid \fIset PAD\fR \| message received. 
  357. .PP
  358. 3.1.5
  359. Table 1/X.29 specifies the PAD's response of the PAD to \fIset\fR ,
  360. \fIset and read\fR , and \fIread PAD\fR \| messages.
  361. .PP
  362. 3.1.6
  363. If the function of a character is duplicated by the selection of parameter 
  364. values by use of the \fIset\fR \| or \fIset and read PAD\fR message, the 
  365. PAD 
  366. will consider these parameter changes as valid, and will respond as described 
  367. in this Recommendation. After these changes are invoked, the PAD will follow 
  368. the procedure described in Recommendation\ X.28, \(sc\ 3.3.2.
  369. .sp 2P
  370. .LP
  371. 3.2
  372.     \fIProcedures for inviting the PAD to clear\fR 
  373. .sp 1P
  374. .RT
  375. .PP
  376. 3.2.1
  377. The 
  378. \fIinvitation to clear PAD\fR \| message
  379. is used to
  380. request that the PAD clears the virtual call, after transmission of all data
  381. previously transmitted to the start\(hystop mode DTE.
  382. .sp 9p
  383. .RT
  384. .PP
  385. \fINote\fR \ \(em\ The \fIclear indication\fR \| packet, which is transmitted 
  386. by the PAD after delivery of the last character to the start\(hystop mode 
  387. DTE, will have a clearing cause field set to \fIDTE clearing\fR . 
  388. .sp 2P
  389. .LP
  390. 3.3
  391.     \fIInterrupt and \fR \fIdiscard\fR \fIprocedures\fR 
  392. .sp 1P
  393. .RT
  394. .PP
  395. 3.3.1
  396. If parameter 7 is set to 21, the PAD will transmit an
  397. \fIinterrupt\fR \| packet with all bits of the interrupt user data field 
  398. set to\ 0 
  399. followed by an \fIindication of break PAD\fR message to indicate that the 
  400. PAD, at the request of the start\(hystop mode DTE, is discarding the user 
  401. sequences 
  402. received. The \fIPAD\fR message will contain an indication in its parameter 
  403. field that parameter\ 8 has been set to\ 1 (\fIdiscard output\fR ). 
  404. .sp 9p
  405. .RT
  406. .PP
  407. 3.3.2
  408. Before resuming data transmission to the PAD, the response to the
  409. \fIindication of break PAD\fR \| message
  410. shall be a \fIset\fR or \fIset and read\fR \fIPAD\fR message, indicating 
  411. that parameter\ 8 should be set to\ 0 (\fInormal data\fR \fIdelivery\fR 
  412. ). 
  413. .PP
  414. Prior to sending this PAD message, any in\(hyprogress complete packet sequence 
  415. being transmitted to the PAD must be terminated (with a packet that 
  416. will be discarded by the PAD) in accordance with Recommendation\ X.25
  417. procedures.
  418. .bp
  419. .ce
  420. \fBH.T. [T1.29]\fR 
  421. .ce
  422. TABLE\ 1/X.29
  423. .ce
  424. \fBPAD messages transmitted by the PAD in response to set, set\fR 
  425. .ce
  426. \fBand read, and read PAD messages\fR 
  427. .ps 9
  428. .vs 11
  429. .nr VS 11
  430. .nr PS 9
  431. .TS
  432. center box;
  433. cw(24p) sw(48p) | cw(78p) | cw(78p) , c | c | ^ | ^ .
  434. T{
  435. PAD message received by the PAD
  436. T}    Action upon PAD parameters    T{
  437. Corresponding \fIparameter indication PAD\fR
  438. message transmitted
  439. to the packet mode \fIDTE\fR
  440. T}
  441. Type    Parameter field
  442. _
  443. .T&
  444. cw(24p) | lw(48p) | lw(78p) | lw(78p) , ^  | l | l | l.
  445. Set    None    T{
  446. Reset all implemented Recommendation\ X.3 parameters to their
  447. initial values corresponding to the initial profile
  448. T}    None
  449.     T{
  450. List of selected parameters with the desired values
  451. T}    T{
  452. Set the selected parameters to the given values:
  453. a)
  454. if no error is encountered
  455. b)
  456. if the PAD fails to modify the values of some parameters
  457. T}    T{
  458. Positionner les param\*`etres choisis aux valeurs
  459. indiqu\*'ees:
  460. a)
  461. None
  462. b)
  463. List of these invalid parameters
  464. (see\ Note)
  465. T}
  466. _
  467. .T&
  468. cw(24p) | lw(48p) | lw(78p) | lw(78p) , ^  | l | l | l.
  469. Set and read    None    T{
  470. Reset all implemented Recommendation\ X.3 parameters to their
  471. initial values corresponding to the initial profile
  472. T}    T{
  473. List all implemented Recommendation\ X.3 parameters, and their
  474. initial values
  475. T}
  476.     T{
  477. List of selected parameters with the desired values
  478. T}    T{
  479. Set the selected parameters to the given values
  480. T}    T{
  481. List of these parameters with their new current values
  482. (see Note)
  483. T}
  484. _
  485. .T&
  486. cw(24p) | lw(48p) | lw(78p) | lw(78p) , ^  | l | l | l.
  487. Read    None    None    T{
  488. List all implemented Recommendation\ X.3 parameters with their
  489. current values
  490. T}
  491.     List of selected parameters    None    T{
  492. List of these parameters with their current
  493. values (see Note)
  494. \fINote\fR
  495. \ \(em\ If any of the parameters contain an error, then the error bit is set and the value field is coded as described in Table\ 3/X.29.
  496. .parag
  497. T}
  498. _
  499. .TE
  500. .nr PS 9
  501. .RT
  502. .ad r
  503. \fBTableau 1/X.29 [T1.29], p. 1\fR 
  504. .sp 1P
  505. .RT
  506. .ad b
  507. .RT
  508. .PP
  509. 3.3.3
  510. If a PAD receives an \fIindication of break PAD\fR \| message which
  511. contains a parameter field as described in \(sc\ 3.3.1 above, it will respond 
  512. by 
  513. transmitting a \fIset PAD\fR message as described in \(sc\ 3.3.2 above and will
  514. transmit a \fIbreak\fR signal to the start\(hystop mode DTE. If a PAD receives 
  515. an 
  516. \fIindication\fR \fIof break PAD\fR message which does not contain a parameter 
  517. field, it will not respond to the packet mode DTE or PAD but it will transmit 
  518. a 
  519. \fIbreak\fR signal to the start\(hystop mode DTE.
  520. .PP
  521. 3.3.4
  522. When the PAD transmits an \fIinterrupt\fR \| packet after the receipt
  523. from the start\(hystop mode DTE of an \fIinterrupt PAD command\fR signal 
  524. or a \fIbreak\fR signal, when parameter\ 7 is set to\ 1, the interrupt 
  525. user data field is 
  526. coded in bits\ 8 to\ 1 as\ 00000001.
  527. .PP
  528. 3.3.5
  529. If the PAD receives an \fIinterrupt\fR \| packet it will confirm it in 
  530. accordance with Recommendation\ X.25 procedures. The PAD will not transmit 
  531. the contents of the interrupt user data field to the start\(hystop DTE. 
  532. The PAD will ignore the values of the interrupt user data field. It is 
  533. for further study 
  534. whether the coding of this field given in \(sc\ 3.3.4 above causes a different
  535. response.
  536. .PP
  537. 3.3.6
  538. If parameter 7 is set to 5, the PAD will transmit an \fIinterrupt\fR \| 
  539. packet with all bits of the \fIinterrupt\fR \| packet set to 0, followed 
  540. by an 
  541. \fIindication of break PAD\fR message. The \fIPAD\fR message will not contain a
  542. parameter field as described in \(sc\ 4.4.7.
  543. .PP
  544. 3.3.7
  545. Some PADs may always send the break signal to the start\(hystop mode DTE 
  546. upon receipt of an \fIinterrupt\fR \| packet rather than upon receipt of 
  547. an 
  548. \fIindication of break PAD\fR message.
  549. .bp
  550. .sp 1P
  551. .LP
  552. 3.4
  553.     \fIProcedure for resets\fR 
  554. .sp 9p
  555. .RT
  556. .PP
  557. Virtual calls may be reset according to the procedures defined in Recommendation\ 
  558. X.25. The effect of the resetting procedure on the value of PAD parameter\ 
  559. 8 is to reset its value to\ 0 (\fInormal data delivery\fR ). The current 
  560. values of all other PAD parameters are not affected.
  561. .RT
  562. .sp 2P
  563. .LP
  564. 3.5
  565.     \fIError handling procedures by the PAD\fR 
  566. .sp 1P
  567. .RT
  568. .PP
  569. 3.5.1
  570. If the PAD receives a \fIset\fR , \fIread\fR \| or \fIset and read PAD\fR \|
  571. message containing an invalid reference to a PAD parameter, the parameter 
  572. field within the \fIparameter indication PAD\fR message transmitted by 
  573. the PAD will 
  574. contain an indication that this has occurred. The remaining valid references 
  575. to PAD parameters are processed by the PAD. 
  576. .sp 9p
  577. .RT
  578. .PP
  579. Possible reasons for an invalid access to a PAD parameter
  580. are:
  581. .LP
  582.     a)
  583.     the parameter reference has not been implemented in the
  584. PAD;
  585. .LP
  586.     b)
  587.     the parameter value has not been implemented in the PAD or
  588. cannot be altered from the current setting;
  589. .LP
  590.     c)
  591.     the parameter is a read\(hyonly one (\fIset\fR and \fIset and read\fR 
  592. \fIPAD\fR messages only);
  593. .LP
  594.     d)
  595.     the parameter follows an invalid parameter separator (see
  596. \(sc\ 4.4.5.4 below).
  597. .PP
  598. 3.5.2
  599. The PAD will transmit an \fIerror PAD\fR \| message containing the
  600. message code of an invalid \fIPAD\fR \| message received under the following
  601. conditions:
  602. .LP
  603.     a)
  604.     if the PAD receives an unrecognizable message code;
  605. .LP
  606.     b)
  607.     if the parameter field following a recognizable message code
  608. is incorrect or incompatible with the message code;
  609. .LP
  610.     c)
  611.     if the parameter field following a recognizable message code
  612. has an invalid format;
  613. .LP
  614.     d)
  615.     if the PAD receives an unsolicited \fIparameter indication\fR 
  616. \fIPAD\fR \| message;
  617. .LP
  618.     e)
  619.     if the PAD receives a PAD message that is too
  620. long.
  621. .PP
  622. 3.5.3
  623. The PAD will transmit an 
  624. \fIerror PAD\fR \| message
  625. if a
  626. \fIPAD\fR \| message containing less than 8\ bits is received.
  627. .PP
  628. 3.5.4
  629. If the PAD receives an \fIerror PAD\fR \| message it will not respond
  630. with a \fIPAD\fR \| message of any type. Subsequent action is for further
  631. study.
  632. .sp 1P
  633. .LP
  634. 3.6
  635.     \fIProcedures for inviting the PAD to reselect the called DTE\fR 
  636. .sp 9p
  637. .RT
  638. .PP
  639. The \fIreselection or reselection with \fR \fITOA/NPI PAD\fR message (Type 
  640. of address/Numbering Plan Indicator) used by a packet mode DTE to request 
  641. that the PAD clear the virtual call, after transmission to the start\(hystop 
  642. mode DTE of all the previously transmitted data. Then, the PAD will establish 
  643. a call to the reselected DTE. 
  644. .PP
  645. \fINote\fR \ \(em\ The TAO/NPI address subscription facility is designated in
  646. Recommendation X.2 for further study.
  647. .PP
  648. When the \fIreselection PAD message\fR \| is received, the PAD will transmit 
  649. an \fIerror PAD message\fR \| with an error type \fIunauthorized reselection 
  650. PAD\fR 
  651. \fImessage\fR (00000110) under the following conditions:
  652. .RT
  653. .LP
  654.     a)
  655.     the virtual call has been established by the packet\(hymode
  656. DTE;
  657. .LP
  658.     b)
  659.      the \fIcalled DTE reselection prevention facility\fR \| has been requested 
  660. by the start\(hystop mode DTE; 
  661. .LP
  662.     c)
  663.      the \fIreselection PAD message\fR has been already received more than 
  664. N times (where N is for further study). 
  665. .PP
  666. The format of the \fIreselection PAD\fR \| message is given in \(sc\ 4.4.9 
  667. below. The format of the \fIreselection with TOA/NPI\ PAD\fR message is 
  668. given in 
  669. \(sc\ 4.4.10 below. These messages contain the information needed by the PAD to
  670. establish the new virtual call.
  671. .PP
  672. Upon receipt of the \fIreselection\fR or \fIreselection with TOA/NPI PAD\fR 
  673. \| message, the PAD will: 
  674. .RT
  675. .LP
  676.     \(em
  677.     transmit to the start\(hystop mode DTE all previously received
  678. data;
  679. .LP
  680.     \(em
  681.     clear the virtual call that is established;
  682. .bp
  683. .LP
  684.     \(em
  685.     after having made the appropriate state changes as described
  686. in Recommendation\ X.28, \(sc\ 3.2.5, establish a virtual call to the
  687. reselected DTE. The \fIcall request packet\fR sent by the PAD, will
  688. contain only the facilities subscribed by the start\(hystop mode
  689. DTE and/or assigned by default. Any other facilities contained
  690. in the \fIreselection PAD message\fR will be ignored. In
  691. particular:
  692. .LP
  693.     i)
  694.      \fIClosed User Group Signals\fR \ \(em\ Independently by the CUG indicated 
  695. in the \fIreselection PAD message\fR , the PAD will use the same CUG of 
  696. the original call.
  697. .LP
  698.     ii)
  699.     \fIReverse Charging\fR \ \(em\ If the start\(hystop mode DTE was   not
  700. charged for the original call the reselected call will not be charged to the
  701. start\(hystop mode DTE, independently of the indication in the \fIreselection 
  702. PAD\fR \fImessage\fR (i.e.,\ the PAD will use the \fIreverse charging\fR 
  703. facility in the 
  704. \fIcall request packet\fR ). If the start\(hystop mode DTE was charged 
  705. for the original call, the reselected call will be charged to the reselected 
  706. DTE if the 
  707. \fIreselection PAD message\fR contains the \fIreverse charging\fR facility.
  708. .LP
  709.     iii)
  710.     \fICharging information\fR :
  711. .LP
  712.     \(em
  713.     facility assigned for an agreed contractual
  714. period: The information will be sent to the start\(hystop mode DTE at
  715. the clearing of each call (original and reselected), or at the clearing 
  716. of the last reselected call. If the later procedure was selected, the PAD 
  717. will send 
  718. the total charging information, without sending the charge of the individual
  719. calls (original and reselected).
  720. .LP
  721.     \(em
  722.     facility on a per call basis: The PAD follows
  723. the procedure indicated above, starting from the first
  724. \fIcharging information facility request\fR (by the start\(hystop mode 
  725. DTE or packet mode DTE). 
  726. .LP
  727.     iv)
  728.     \fIRPOA selection:\fR \ for further study
  729. .LP
  730.     \fINote\fR \ \(em\ The other facilities indicated in Table 4/X.28
  731. with \fINote 2\fR \| are for further study.
  732. .PP
  733. \fINote\fR \ \(em\ This procedure is an optional feature of the PAD. PADs
  734. which do not implement this feature will consider \fIreselection\fR and
  735. \fIreselection with TOA/NPI\ PAD\fR messages as invalid. PADs may implement 
  736. this 
  737. feature either by accepting (1)\ \fIreselection PAD\fR messages or (2)\ 
  738. \fIreselection\fR and \fIreselection with\fR \fITOA/NPI\ PAD\fR messages. 
  739. The sending of 
  740. \fIreselection or reselection with\fR \fITOA/NPI\ PAD\fR messages by a 
  741. PAD is for 
  742. further study.
  743. .sp 2P
  744. .LP
  745. \fB4\fR     \fBFormats\fR 
  746. .sp 1P
  747. .RT
  748. .sp 1P
  749. .LP
  750. 4.1
  751.     \fIIntroduction\fR 
  752. .sp 9p
  753. .RT
  754. .PP
  755. Bits of octets are numbered 8 to 1 where bit 1 is the low order
  756. bit and is transmitted first. Octets of the call user data, of user sequences, 
  757. of \fIPAD\fR messages and of interrupt user data are consecutively numbered 
  758. starting from\ 1 and are transmitted in this order.
  759. .RT
  760. .sp 1P
  761. .LP
  762. 4.2
  763.     \fICall user data format\fR \|(see Figure 1/X.29)
  764. .sp 9p
  765. .RT
  766. .sp 1P
  767. .LP
  768. 4.2.1
  769.     \fIProtocol identifier format\fR 
  770. .sp 9p
  771. .RT
  772. .PP
  773. The 
  774. protocol identifier field
  775. standardized by CCITT
  776. consists of four octets.
  777. .PP
  778. The first octet is coded as follows:
  779. .RT
  780. .LP
  781.     bits 8 and 7
  782.     =\ 00 for CCITT use
  783. .LP
  784.     =\ 01 for national use
  785. .LP
  786.     =\ 10 reserved for international user bodies
  787. .LP
  788.     =\ 11 for DTE\(hyDTE use.
  789. .PP
  790. When bits 8 and 7 are equal to 00, bits 6 to 1 are equal to\ 000001 for 
  791. indicating \fIPAD\fR \| messages relating to the \fIpacket assembly/disassembly\fR 
  792. facility for the start\(hystop mode DTE. Other coding of bits\ 6 to\ 1 
  793. is reserved for future standardization by the CCITT, subject to the rules 
  794. of 
  795. Recommendation\ X.244. All bits of octets\ 2, 3 and 4 are set to\ 0. These 
  796. octets are reserved as a future mechanism for providing the called PAD 
  797. or packet mode DTE with additional information pertinent to the calling 
  798. party. 
  799. .bp
  800. .LP
  801. .rs
  802. .sp 26P
  803. .ad r
  804. \fBFigure\ 1/X.29, (MC), p.\fR 
  805. .sp 1P
  806. .RT
  807. .ad b
  808. .RT
  809. .sp 1P
  810. .LP
  811. 4.2.2
  812.     \fICall data format\fR 
  813. .sp 9p
  814. .RT
  815. .PP
  816. Octets of the 
  817. call data field
  818. will contain the user
  819. characters received by the PAD from the start\(hystop mode DTE during the call
  820. establishment phase. The coding of these octets is similar to that of user
  821. sequences (see \(sc\ 4.3 below). The call data field is limited to 12\ 
  822. octets (see Figure\ 1/X.29). 
  823. .RT
  824. .sp 2P
  825. .LP
  826. 4.3
  827.     \fIUser sequence format\fR 
  828. .sp 1P
  829. .RT
  830. .PP
  831. 4.3.1
  832. The order of bit transmission from the PAD is the same as the order that 
  833. bits are received from the start\(hystop mode DTE. The order of bit 
  834. transmission to the start\(hystop mode DTE is the same as the order that 
  835. bits are received. 
  836. .sp 9p
  837. .RT
  838. .PP
  839. 4.3.2
  840. No maximum is specified for the length of a user sequence.
  841. .sp 2P
  842. .LP
  843. 4.4
  844.     \fIControl message format\fR 
  845. .sp 1P
  846. .RT
  847. .PP
  848. 4.4.1
  849. Bits 8, 7, 6, 5 of octet 1 of a user data field of complete
  850. packet sequences with Q\ =\ 1 are defined as the \fIcontrol identifier 
  851. field\fR , used to identify the facility, such as PAD, to be controlled. 
  852. The 
  853. control
  854. identifier field
  855. coding for \fIPAD\fR messages to control a PAD for a
  856. start\(hystop mode DTE is\ 0000. Other codings of the control identifier 
  857. field are reserved for future standardization. 
  858. .sp 9p
  859. .RT
  860. .PP
  861. \fINote\fR \ \(em\ The possibility of extending the control identifier 
  862. field is for further study. 
  863. .PP
  864. 4.4.2
  865. When the control identifier field (see \(sc\ 4.4.1 above) is set
  866. to\ 0000, bits\ 4, 3, 2, 1 of octet\ 1 are defined as the 
  867. message code
  868. field
  869. . The \fImessage code\fR field is used to identify specific types of \fIPAD\fR 
  870. messages, as given in Table\ 2/X.29. 
  871. .bp
  872. .ce
  873. \fBH.T. [T2.29]\fR 
  874. .ce
  875. TABLE\ 2/X.29
  876. .ce
  877. \fBType and coding of octet 1 of PAD messages\fR 
  878. .ps 9
  879. .vs 11
  880. .nr VS 11
  881. .nr PS 9
  882. .TS
  883. center box;
  884. cw(144p) | cw(30p) sw(15p) sw(15p) sw(15p) sw(9p) , ^  | c | c | c | c | c.
  885. Type    Message code
  886.     Bits    4    3    2    1
  887. _
  888. .T&
  889. lw(144p) | lw(30p) | cw(15p) | cw(15p) | cw(15p) | cw(9p) .
  890. Set PAD message        0    0    1    0
  891. .T&
  892. lw(144p) | lw(30p) | cw(15p) | cw(15p) | cw(15p) | cw(9p) .
  893. Read PAD message        0    1    0    0
  894. .T&
  895. lw(144p) | lw(30p) | cw(15p) | cw(15p) | cw(15p) | cw(9p) .
  896. Set and read PAD message        0    1    1    0
  897. .T&
  898. lw(144p) | lw(30p) | cw(15p) | cw(15p) | cw(15p) | cw(9p) .
  899. T{
  900. Parameter indication PAD message
  901. T}        0    0    0    0
  902. .T&
  903. lw(144p) | lw(30p) | cw(15p) | cw(15p) | cw(15p) | cw(9p) .
  904. T{
  905. Invitation to clear PAD message
  906. T}        0    0    0    1
  907. .T&
  908. lw(144p) | lw(30p) | cw(15p) | cw(15p) | cw(15p) | cw(9p) .
  909. T{
  910. Indication of break PAD message
  911. T}        0    0    1    1
  912. .T&
  913. lw(144p) | lw(30p) | cw(15p) | cw(15p) | cw(15p) | cw(9p) .
  914. Reselection PAD message        0    1    1    1
  915. .T&
  916. lw(144p) | lw(30p) | cw(15p) | cw(15p) | cw(15p) | cw(9p) .
  917. Error PAD message        0    1    0    1
  918. .T&
  919. lw(144p) | lw(30p) | cw(15p) | cw(15p) | cw(15p) | cw(9p) .
  920. Reselection with TOA/NPI        1    0    0    T{
  921. 0
  922. \fINote\fR
  923. \ \(em\ The possibility of extending the message code field is for further
  924. study.
  925. .parag
  926. T}
  927. _
  928. .TE
  929. .nr PS 9
  930. .RT
  931. .ad r
  932. \fBTable 2/X.29 [T2.29], p.\fR 
  933. .sp 1P
  934. .RT
  935. .ad b
  936. .RT
  937. .LP
  938. .sp 1
  939. .PP
  940. 4.4.3
  941. All \fIPAD\fR \| messages consist of a control identifier field
  942. (bits 8, 7, 6, 5 of octet\ 1 equal to\ 0000) and a message code field (bits\ 
  943. 4, 3, 2, 1 of octet\ 1). 
  944. .PP
  945. \fISet\fR , \fIread\fR , \fIset and read\fR and \fIparameter indication 
  946. PAD\fR \| 
  947. messages consist of octet\ 1 which may be followed by one or more parameter
  948. fields. Each parameter field consists of a 
  949. parameter reference octet
  950. and a 
  951. parameter value octet
  952. .
  953. .PP
  954. The parameter value octets of the \fIread PAD\fR \| message contain the
  955. value\ 0.
  956. .PP
  957. The \fIerror PAD\fR \| message consists of octet 1 and one or two octets
  958. giving the reason for the error.
  959. .PP
  960. The \fIindication of break PAD\fR \| message consists of octet 1 which 
  961. may be followed by a parameter field. 
  962. .PP
  963. The \fIinvitation to clear PAD\fR \| message consists of octet 1
  964. only.
  965. .RT
  966. .PP
  967. 4.4.4
  968. The maximum length of PAD message is network dependent, but
  969. will be at least 128\ octets.
  970. .sp 1P
  971. .LP
  972. 4.4.5
  973.      \fIParameter field\fR \fIfor \fR \fIset, read, set and read, and\fR \fIparameter 
  974. indication PAD messages\fR \| (see Figure\ 2/X.29) 
  975. .sp 9p
  976. .RT
  977. .PP
  978. A parameter field contained in one of these \fIPAD\fR messages
  979. consists of a 
  980. reference field
  981. and a 
  982. value field
  983. . A parameter
  984. field is two octets in length, except when the extension mechanism is used 
  985. (see \(sc\ 4.4.5.1 below). 
  986. .RT
  987. .PP
  988. 4.4.5.1
  989. A reference field consists of a parameter reference, identified
  990. as a decimal number in Recommendation\ X.3, and is binary coded in bits\ 7
  991. to\ 1, where bit\ 1 is the low order bit. Reference fields need not be 
  992. ordered by increasing parameter reference numbers. 
  993. .PP
  994. The code 1111111 (decimal 127) in bits 7 to 1 of the reference
  995. field will be used for the extension of this field. Such coding will indicate 
  996. that there is another octet following. The following octet is coded with 
  997. the 
  998. parameter reference of Recommendation\ X.3 minus 127.
  999. .PP
  1000. 4.4.5.2
  1001. In \fIPAD\fR \| messages received by the PAD, bit\ 8 of each octet
  1002. will be ignored. In \fIparameter indication PAD\fR messages, bit\ 8 of each
  1003. reference field set to\ 1 will indicate an invalid access to the referred
  1004. parameter as described in \(sc\ 3.5 above.
  1005. .bp
  1006. .LP
  1007. .rs
  1008. .sp 32P
  1009. .ad r
  1010. \fBFigure 2/X.29, (M), p. 4\fR 
  1011. .sp 1P
  1012. .RT
  1013. .ad b
  1014. .RT
  1015. .PP
  1016. 4.4.5.3
  1017. A parameter value field consists of a value of the parameter
  1018. reference, identified as a decimal number in Recommendation\ X.3, and is
  1019. binary coded in bits\ 8 to\ 1, where bit\ 1 is the low order bit. Value 
  1020. fields in \fIread PAD\fR messages are coded as all binary\ 0s. In \fIset\fR 
  1021. and \fIset and read\fR 
  1022. \fIPAD\fR messages, they will indicate the requested values of parameters. In
  1023. \fIparameter indication PAD\fR messages, they will indicate the current 
  1024. values of PAD parameters, after modification if any. If bit\ 8 (error bit) 
  1025. is set to\ 1 in the preceding octet (i.e.\ the parameter reference field), 
  1026. the parameter value field will indicate the reason for the error, as given 
  1027. in Table\ 3/X.29. 
  1028. .PP
  1029. 4.4.5.4
  1030. Parameters not standardized by CCITT may be supported. The
  1031. parameter separator is used in PAD messages to indicate the separation 
  1032. between parameters specified in Recommendation\ X.3 and any others implemented 
  1033. nationally or locally.
  1034. .PP
  1035. The parameter separator consists of a parameter field which
  1036. contains a reference field set to 00000000 and a value field set to
  1037. 00000000.
  1038. .PP
  1039. When present, the parameter separator and the national or local
  1040. parameter fields must be placed after any CCITT standardized parameter 
  1041. fields in PAD messages. 
  1042. .PP
  1043. \fINote\fR \ \(em\ It is recommended that only the parameters defined in
  1044. Recommendation\ X.3 are used when communicating with a PAD in a different
  1045. country or network.
  1046. .bp
  1047. .RT
  1048. .ce
  1049. \fBH.T. [T3.29]\fR 
  1050. .ce
  1051. TABLE\ 3/X.29
  1052. .ce
  1053. \fBCoding of parameter value field in case of error\fR 
  1054. .ps 9
  1055. .vs 11
  1056. .nr VS 11
  1057. .nr PS 9
  1058. .TS
  1059. center box;
  1060. cw(120p) | cw(12p) sw(6p) sw(12p) sw(6p) sw(12p) sw(6p) sw(12p) sw(6p) sw(24p) , ^  | c s s s s s s s 
  1061. ^  | c | c | c | c | c | c | c | c | c.
  1062. Error type    Parameter value field code
  1063.     Bits    8    7    6    5    4    3    2    1    Decimal
  1064. _
  1065. .T&
  1066. lw(120p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(24p) .
  1067. No additional information    0    0    0    0    0    0    0    0    0
  1068. .T&
  1069. lw(120p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(24p) .
  1070. T{
  1071. The parameter reference does not exist or has not been implemented in
  1072. the PAD
  1073. T}    0    0    0    0    0    0    0    1    1
  1074. .T&
  1075. lw(120p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(24p) .
  1076. T{
  1077. The parameter value is invalid or has not been implemented in the PAD
  1078. T}    0    0    0    0    0    0    1    0    2
  1079. .T&
  1080. lw(120p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(24p) .
  1081. T{
  1082. The parameter value cannot be altered from the current setting
  1083. T}    0    0    0    0    0    0    1    1    3
  1084. .T&
  1085. lw(120p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(24p) .
  1086. The parameter is read\(hyonly    0    0    0    0    0    1    0    0    4
  1087. .T&
  1088. lw(120p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(24p) .
  1089. T{
  1090. The parameter follows an invalid parameter separator
  1091. T}    0    0    0    0    0    1    0    1    T{
  1092. 5
  1093. \fINote\fR
  1094. \ \(em\ The value 0 is mandatory. Other values are optional.
  1095. .parag
  1096. T}
  1097. _
  1098. .TE
  1099. .nr PS 9
  1100. .RT
  1101. .ad r
  1102. \fBTable 3/X.29 [T3.29], p.\fR 
  1103. .sp 1P
  1104. .RT
  1105. .ad b
  1106. .RT
  1107. .sp 1P
  1108. .LP
  1109. 4.4.6
  1110.     \fIFormat of error PAD messages\fR \| (see Figure 3/X.29)\fR 
  1111. .sp 9p
  1112. .RT
  1113. .LP
  1114. .rs
  1115. .sp 13P
  1116. .ad r
  1117. \fBFigure 3/X.29, (M), p.\fR 
  1118. .sp 1P
  1119. .RT
  1120. .ad b
  1121. .RT
  1122. .PP
  1123. 4.4.6.1
  1124. Octet 2 of the \fIerror PAD\fR \| message will be coded as shown in
  1125. Table\ 4/X.29.
  1126. .PP
  1127. 4.4.6.2
  1128. In cases b, c, d, e and f in Table 4/X.29, octet 3 of
  1129. an \fIerror PAD\fR \| message will contain the message code of the received 
  1130. \fIPAD\fR 
  1131. message.
  1132. .sp 1P
  1133. .LP
  1134. 4.4.7
  1135.     \fIParameter field for indication of break PAD messages\fR \|
  1136. (see Figure\ 4/X.29)
  1137. .sp 9p
  1138. .RT
  1139. .PP
  1140. This \fIPAD\fR \| message may either not contain a parameter field, or
  1141. contain a parameter field consisting of 2\ octets (i.e.\ one reference 
  1142. field and one value field) coded as follows: the reference field will be 
  1143. coded 00001000 (indicating parameter\ 8) and the value field will be coded 
  1144. 00000001 (indicating decimal\ 1). 
  1145. .bp
  1146. .RT
  1147. .LP
  1148. .rs
  1149. .sp 27P
  1150. .ad r
  1151. \fBCuadro 4/X.29 [T4.29] p.\fR 
  1152. .sp 1P
  1153. .RT
  1154. .ad b
  1155. .RT
  1156. .LP
  1157. .rs
  1158. .sp 10P
  1159. .ad r
  1160. \fBFigure 4/X.29, (M), p.\fR 
  1161. .sp 1P
  1162. .RT
  1163. .ad b
  1164. .RT
  1165. .sp 1P
  1166. .LP
  1167. 4.4.8
  1168.     \fIParameter field for invitation to clear PAD message\fR \|
  1169. (see Figure\ 5/X.29)
  1170. .sp 9p
  1171. .RT
  1172. .LP
  1173. .rs
  1174. .sp 6P
  1175. .ad r
  1176. \fBFigure 5/X.29, (M), p.\fR 
  1177. .sp 1P
  1178. .RT
  1179. .ad b
  1180. .RT
  1181. .PP
  1182. This \fIPAD\fR \| message will not contain a parameter field.
  1183. .bp
  1184. .sp 1P
  1185. .LP
  1186. 4.4.9
  1187.     \fI\fIReselection PAD message format\fR 
  1188. .sp 9p
  1189. .RT
  1190. .PP
  1191. The format of this message is given in Figure\ 6/X.29.
  1192. .RT
  1193. .LP
  1194. .rs
  1195. .sp 19P
  1196. .ad r
  1197. \fBFigure 6/X.29, (MC), p.\fR 
  1198. .sp 1P
  1199. .RT
  1200. .ad b
  1201. .RT
  1202. .sp 1P
  1203. .LP
  1204. 4.4.9.1
  1205.     \fIReselected DTE address length field\fR 
  1206. .sp 9p
  1207. .RT
  1208. .PP
  1209. Bits 4, 3, 2 and 1 of the reselected DTE address length field
  1210. indicate the length of the reselected DTE address in semi\(hyoctets. The 
  1211. address length is binary coded and bit\ 1 is the low order bit of the 
  1212. indicator.
  1213. .RT
  1214. .sp 1P
  1215. .LP
  1216. 4.4.9.2
  1217.     \fIAddress field\fR 
  1218. .sp 9p
  1219. .RT
  1220. .PP
  1221. Octet 3 and the following octets consist of the reselected DTE
  1222. address. Each digit of the address is coded in a semi\(hyoctet in binary coded
  1223. decimal with bit\ 5 or\ 1 being the low order bit of the digit.
  1224. .PP
  1225. Starting from the high order digit, the address is coded in octet\ 3
  1226. and consecutive octets with two digits per octet. In each octet, the higher
  1227. order digit is coded in bits\ 8, 7, 6 and\ 5.
  1228. .PP
  1229. The address field shall be rounded up to an integral number of octets by 
  1230. inserting zeros in bits\ 4, 3, 2 and\ 1 of the last octet of the field 
  1231. when 
  1232. necessary.
  1233. .PP
  1234. The reselected DTE address field should contain the
  1235. \fIinternational data number\fR (DNIC\ +\ Network terminal
  1236. number).
  1237. .RT
  1238. .sp 1P
  1239. .LP
  1240. 4.4.9.3
  1241.     \fIFacility length field\fR 
  1242. .sp 9p
  1243. .RT
  1244. .PP
  1245. The octet following the reselected DTE address field indicates the length 
  1246. of the facility field, in octets. The facility length indicator is 
  1247. binary coded and bit\ 1 is the low order bit of the indicator.
  1248. .RT
  1249. .sp 1P
  1250. .LP
  1251. 4.4.9.4
  1252.     \fIFacility field\fR 
  1253. .sp 9p
  1254. .RT
  1255. .PP
  1256. The facility field is present only when optional user facilities
  1257. are included by the DTE. This field indicates the facilities that must be
  1258. included in the facility field of the \fIincoming call\fR packet received 
  1259. by the 
  1260. reselected DTE (see \(sc\ 3.6).
  1261. .PP
  1262. The coding of the facility field is defined in \(sc\ 7 of
  1263. Recommendation\ X.25.
  1264. .PP
  1265. The facility field contains an integral number of octets, the
  1266. maximum length of the complete PAD message is restricted, as described in
  1267. \(sc\ 4.4.4 above.
  1268. .bp
  1269. .RT
  1270. .sp 1P
  1271. .LP
  1272. 4.4.9.5
  1273.     \fICall user data field\fR 
  1274. .sp 9p
  1275. .RT
  1276. .PP
  1277. Following the facility field, the call user data field may be
  1278. present and has a maximum length of 12 octets.
  1279. .PP
  1280. Call user data when present in the call user data field of the
  1281. \fIreselection PAD\fR message is included in the call user data field of the
  1282. \fIincoming call\fR packet received by the reselected DTE.
  1283. .RT
  1284. .sp 1P
  1285. .LP
  1286. 4.4.10
  1287.     \fIReselection with TOA/NPI PAD message format\fR 
  1288. .sp 9p
  1289. .RT
  1290. .PP
  1291. The format of this message is given in Figure 7/X.29.
  1292. .PP
  1293. \fINote\fR \ \(em\ The TOA/NPI address subscription facility is designated in
  1294. Recommendation\ X.2 for further study.
  1295. .RT
  1296. .LP
  1297. .rs
  1298. .sp 16P
  1299. .ad r
  1300. \fBFigure 7/X.29, (N), p.\fR 
  1301. .sp 1P
  1302. .RT
  1303. .ad b
  1304. .RT
  1305. .sp 1P
  1306. .LP
  1307. 4.4.10.1
  1308.     \fIReselected DTE address length field\fR 
  1309. .sp 9p
  1310. .RT
  1311. .PP
  1312. Octet 2 indicates the length of the reselected DTE address in
  1313. semi\(hyoctets. The address length is binary coded and bit\ 1 is the low 
  1314. order bit of the indicator. The maximum value of the reselected DTE address 
  1315. length field is 17. 
  1316. .RT
  1317. .sp 1P
  1318. .LP
  1319. 4.4.10.2
  1320.     \fIReselected DTE address field\fR 
  1321. .sp 9p
  1322. .RT
  1323. .PP
  1324. Octet 3 will consist of the TOA/NPI indication as described in
  1325. Recommendation X.25. The following octets consist of the reselected DTE
  1326. address. Each digit of the address is coded in a semi\(hyoctet in binary coded
  1327. decimal with bit\ 5 or\ 1 being the low order bit of the digit. Starting 
  1328. from the high order digit, the address digits are coded in consecutive 
  1329. semi\(hyoctets. In each octet, the higher order digit is coded in bits\ 
  1330. 8, 7, 6 and\ 5. 
  1331. .RT
  1332. .sp 1P
  1333. .LP
  1334. 4.4.10.3
  1335.     \fIFacility length field\fR 
  1336. .sp 9p
  1337. .RT
  1338. .PP
  1339. The octet following the address field indicates the length of the facility 
  1340. field, in octets. The facility length indicator is binary coded and 
  1341. bit\ 1 is the low order bit of the indicator.
  1342. .RT
  1343. .sp 1P
  1344. .LP
  1345. 4.4.10.4
  1346.     \fIFacility field\fR 
  1347. .sp 9p
  1348. .RT
  1349. .PP
  1350. (See \(sc 4.4.9.4.)
  1351. .RT
  1352. .sp 1P
  1353. .LP
  1354. 4.4.10.5
  1355.     \fICall user data field\fR 
  1356. .sp 9p
  1357. .RT
  1358. .PP
  1359. (See \(sc 4.4.9.5.)
  1360. .bp
  1361. .RT
  1362. .ce 1000
  1363. ANNEX\ A
  1364. .ce 0
  1365. .ce 1000
  1366. (to Recommendation X.29)
  1367. .sp 9p
  1368. .RT
  1369. .ce 0
  1370. .ce 1000
  1371. \fBCharacteristics of \fR \fBvirtual calls\fR \fBand Recommendation X.25\fR 
  1372. .sp 1P
  1373. .RT
  1374. .ce 0
  1375. .ce 1000
  1376. \fBas related to the PAD representation of\fR 
  1377. .ce 0
  1378. .ce 1000
  1379. \fBa start\(hystop mode DTE to a packet mode DTE\fR 
  1380. .ce 0
  1381. .LP
  1382. A.1
  1383.     \fIGeneral interface characteristics\fR 
  1384. .sp 1P
  1385. .RT
  1386. .PP
  1387. A.1.1
  1388. The mechanical, electrical, functional and procedural
  1389. characteristics to activate, maintain and deactivate the physical access
  1390. path between the DTE and the DCE will be in accordance with the physical 
  1391. level procedures of Recommendation\ X.25. 
  1392. .sp 9p
  1393. .RT
  1394. .PP
  1395. A.1.2
  1396. The link access procedure for data interchange across the link
  1397. between the DTE and DCE will be in accordance with the link level procedures 
  1398. of Recommendation\ X.25. 
  1399. .PP
  1400. A.1.3
  1401. The packet format and control procedures for the exchange of
  1402. packets containing control information and user data between the DTE and the
  1403. DCE will be in accordance with the packet level procedures of
  1404. Recommendation\ X.25.
  1405. .sp 2P
  1406. .LP
  1407. A.2
  1408.     \fIInterface procedures for virtual call control\fR 
  1409. .sp 1P
  1410. .RT
  1411. .PP
  1412. A.2.1
  1413. Incoming calls are indicated to the packet mode DTE as
  1414. specified in Recommendation\ X.25. Call requests are indicated by the packet
  1415. mode DTE as specified in Recommendation\ X.25. Any use of optional user
  1416. facilities are indicated in accordance with \(sc\(sc\ 6 and\ 7 of
  1417. Recommendation\ X.25.
  1418. .sp 9p
  1419. .RT
  1420. .PP
  1421. A.2.2
  1422. The default throughput classes used by the PAD are determined by the data 
  1423. rates of the start\(hystop mode DTE (where exact correspondence is not 
  1424. obtained, the next higher throughput class is used).
  1425. .PP
  1426. A.2.3
  1427. The PAD and the packet mode DTE will use the clearing procedures specified 
  1428. in \(sc\(sc\ 4.1.7, 4.1.8 and\ 4.1.9 of Recommendation\ X.25. 
  1429. .sp 2P
  1430. .LP
  1431. A.3
  1432.     \fIInterface procedures for data transfer\fR 
  1433. .sp 1P
  1434. .RT
  1435. .PP
  1436. A.3.1
  1437. Data transfer on a virtual call can only take place in the
  1438. \fIdata transfer\fR \| state and when flow control permits (see \(sc\ 4.4 of
  1439. Recommendation\ X.25). The same is true for the transfer of \fIinterrupt\fR 
  1440. packets (see \(sc\ 4.3 of Recommendation\ X.25). 
  1441. .sp 9p
  1442. .RT
  1443. .PP
  1444. A.3.2
  1445. \fIInterrupt\fR \| packets transmitted by the packet mode DTE will be
  1446. confirmed by the PAD following the procedures in Recommendation\ X.25.
  1447. .PP
  1448. A.3.3
  1449. The reset procedure may be used by the packet mode DTE or the PAD to re\(hyinitialize 
  1450. the virtual call and will conform to the procedures described in \(sc\ 
  1451. 4.4.3 of Recommendation\ X.25. 
  1452. .PP
  1453. A.3.4
  1454. A reset of the virtual call originated by the packet mode DTE or due to 
  1455. network congestion may be indicated by the PAD to the start\(hystop mode 
  1456. DTE.
  1457. .PP
  1458. A.3.5
  1459. A reset procedure initiated by the PAD may be due either to:
  1460. .LP
  1461.     a)
  1462.     the receipt at the PAD of a request to reset from the
  1463. non\(hypacket mode DTE. The resetting cause contained in the
  1464. \fIreset indication\fR packet will be \fIDTE reset\fR ; or
  1465. .LP
  1466.     b)
  1467.     a PAD or network failure.
  1468. .PP
  1469. A.3.6
  1470. For calls received by the PAD with bit 7 of octet 1 in the
  1471. \fIincoming call\fR \| packet set to\ 0, the PAD will set bit\ 7 of octet\ 
  1472. 1 in the 
  1473. \fIcall accepted\fR packet to\ 0 and will set the D\ bit in transmitted 
  1474. \fIdata\fR 
  1475. packets to\ 0.
  1476. .PP
  1477. Pending further study, and in the absence of bilateral agreement between 
  1478. Administrations (used in conjunction with the D\ bit modification 
  1479. facility), the following applies:
  1480. .PP
  1481. If the \fIincoming call\fR \| packet received by the PAD has bit 7 of
  1482. octet\ 1 set to\ 1, the PAD may set bit\ 7 of octet\ 1 of the \fIcall accepted\fR 
  1483. packet to\ 1.
  1484. .PP
  1485. Calls originated by the PAD will set bit\ 7 of octet\ 1 in \fIcall\fR 
  1486. \fIrequest\fR \| packets to\ 0. The called DTE can indicate if it requires 
  1487. the support of the D\ bit procedure by setting bit\ 7 of octet\ 1 of \fIcall 
  1488. accepted\fR packets to\ 1. 
  1489. .PP
  1490. PAD procedures associated with the Delivery Confirmation (D) bit in
  1491. data packets (see \(sc\ 4.3.3 of Recommendation\ X.25) are described in 
  1492. \(sc\(sc\ 1.4.4 
  1493. and\ 1.5.6.
  1494. .bp
  1495. .RT
  1496. .sp 2P
  1497. .LP
  1498. A.4\fR     \fIVirtual call characteristics\fR 
  1499. .sp 1P
  1500. .RT
  1501. .sp 1P
  1502. .LP
  1503. A.4.1
  1504.     \fIResetting\fR \v'3p'
  1505. .sp 9p
  1506. .RT
  1507. .PP
  1508. A.4.1.1
  1509. There may be a loss of data characters in any case of reset, as
  1510. stated in Recommendation\ X.25. Characters generated by either of the DTEs 
  1511. prior to the \fIreset\fR indication or confirmation will not be delivered 
  1512. to the other 
  1513. DTE after the \fIreset\fR indication or confirmation.
  1514. .sp 2P
  1515. .LP
  1516. A.4.2
  1517.     \fIInterrupt transfer\fR 
  1518. .sp 1P
  1519. .RT
  1520. .PP
  1521. A.4.2.1
  1522. An \fIinterrupt\fR \| packet is always delivered at or before the
  1523. point in the data packet stream at which it was generated.
  1524. .sp 9p
  1525. .RT
  1526. .sp 1P
  1527. .LP
  1528. A.4.3
  1529.     \fICall clearing\fR 
  1530. .sp 9p
  1531. .RT
  1532. .PP
  1533. \fIData\fR \| packets transmitted immediately before a \fIclear request\fR 
  1534. \| packet is sent, may be overtaken within the network by the \fIclear 
  1535. request\fR 
  1536. packet and subsequently be destroyed, as described in \(sc\ 4.5 of
  1537. Recommendation\ X.25.
  1538. .RT
  1539. .sp 2P
  1540. .LP
  1541. \fBRecommendation X.30\fR 
  1542. .FS
  1543. This Recommendation is also included in the Recommendations of the I Series 
  1544. under the number I.461. 
  1545. .FE
  1546. .RT
  1547. .sp 2P
  1548. .ce 1000
  1549. \fBSUPPORT\ OF\ X.21,\ X.21\|\fIbis\fR \fB\ AND\ X.20\|\fR \fIbis\fR \fB\ 
  1550. BASED\ DATA\ TERMINAL\fR \| 
  1551. \fBEQUIPMENTS\ (DTEs)\fR 
  1552. .EF '%    Fascicle\ VIII.2\ \(em\ Rec.\ X.30''
  1553. .OF '''Fascicle\ VIII.2\ \(em\ Rec.\ X.30    %'
  1554. .ce 0
  1555. .sp 1P
  1556. .ce 1000
  1557. \fBBY\ AN\ INTEGRATED\ SERVICES\ DIGITAL\ NETWORK\ (ISDN)\fR 
  1558. .ce 0
  1559. .sp 1P
  1560. .ce 1000
  1561. \fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR 
  1562. .sp 9p
  1563. .RT
  1564. .ce 0
  1565. .sp 1P
  1566. .sp 2P
  1567. .LP
  1568.     The\ CCITT,
  1569. .sp 1P
  1570. .RT
  1571. .sp 1P
  1572. .LP
  1573. \fIconsidering\fR 
  1574. .sp 9p
  1575. .RT
  1576. .PP
  1577. (a)
  1578. that the Integrated Services Digital Network (ISDN)
  1579. will offer the universal interfaces to connect subscriber terminals according 
  1580. to the reference configurations described in Recommendation\ I.411; 
  1581. .PP
  1582. (b)
  1583. that during the evolution of ISDN, however, there will exist for a considerable 
  1584. period DTEs conforming to Recommendations\ X.21, 
  1585. X.21\|\fIbis\fR and X.20\|\fIbis\fR which have to be connected to the ISDN;
  1586. .PP
  1587. (c)
  1588. that the 
  1589. D\(hychannel signalling protocol
  1590. is
  1591. described in Recommendations\ I.430, IQ.920, Q.921,
  1592. Q.930 and Q.931;
  1593. .PP
  1594. (d)
  1595. that the X.21\|\fIbis\fR DTEs are an evolution of V series
  1596. DTEs, which also provide interworking capability with X.21 DTEs over PDN
  1597. services, and which use the network provided signal element timing and may
  1598. have specific call control features to comply with the X.21 calling
  1599. protocol
  1600. .FS
  1601. See Recommendation V.110.
  1602. .FE
  1603. ;
  1604. .PP
  1605. (e)
  1606. that the X.20\|\fIbis\fR based DTEs are an evolution of
  1607. V\ series DTEs, which are operating in the asynchronous mode and which 
  1608. may have call control features to comply with the X.20 calling protocol, 
  1609. .sp 1P
  1610. .LP
  1611. \fIunanimously declares\fR 
  1612. .sp 9p
  1613. .RT
  1614. .PP
  1615. (1)
  1616. that the scope of this Recommendation covers the
  1617. connection of X.21 and X.21\|\fIbis\fR based terminals of user classes 
  1618. of service\ 3 to\ 7 and\ 19 to the ISDN operating in accordance with circuit\(hyswitched 
  1619. or leased circuit services; 
  1620. .PP
  1621. (2)
  1622. that the scope of this Recommendation also covers the
  1623. connection of X.20\|\fIbis\fR based terminals of user classes of service\ 
  1624. 1 and\ 2 and of asynchronous data rates of 600, 1200, 2400, 4800 and\ 9600 
  1625. to the ISDN 
  1626. operating in accordance with circuit\(hyswitched or leased circuit services;
  1627. .bp
  1628. .PP
  1629. (3)
  1630. that the reference configurations of \(sc\ 1 of this
  1631. Recommendation shall apply;
  1632. .PP
  1633. (4)
  1634. that the terminal adaptor (TA) functions to support
  1635. X.21, X.21\|\fIbis\fR and/or X.20\|\fIbis\fR based DTEs including:
  1636. .LP
  1637.     \(em
  1638.     rate adaption functions,
  1639. .LP
  1640.     \(em
  1641.     call establishment functions,
  1642. .LP
  1643.     \(em
  1644.     mapping functions,
  1645. .LP
  1646.     \(em
  1647.     ready for data alignment,
  1648. .LP
  1649. shall be performed as outlined in \(sc\ 2;
  1650. .PP
  1651. (5)
  1652. that the scope of this Recommendation covers the rate
  1653. adaption requirements which are caused by the connection of existing terminals 
  1654. to the ISDN user/network interface, but does not cover the requirements 
  1655. on bit rate conversion caused by the inter\(hyoperation of terminals with 
  1656. different bit rates (ISDN\(hyCSPDN interworking). 
  1657. .sp 1P
  1658. .ce 1000
  1659. CONTENTS
  1660. .ce 0
  1661. .sp 1P
  1662. .sp 2P
  1663. .LP
  1664. 1
  1665.     \fIReference configurations\fR 
  1666. .sp 1P
  1667. .RT
  1668. .LP
  1669.     1.1
  1670.     Customer access configuration
  1671. .LP
  1672.     1.2
  1673.     Network configuration
  1674. .LP
  1675.     1.3
  1676.     Interworking situation
  1677. .sp 1P
  1678. .LP
  1679. 2
  1680.     \fITerminal adaption functions\fR 
  1681. .sp 9p
  1682. .RT
  1683. .LP
  1684.     2.1
  1685.      Terminal adaption functions for DTEs conforming to X.1 user classes of 
  1686. service 3 to 6 
  1687. .LP
  1688.     2.2
  1689.     Terminal adaption functions for DTEs conforming to X.1 user class of service 7
  1690. .LP
  1691.     2.3
  1692.      Terminal adaption functions for DTEs conforming to X.1 user class of 
  1693. service 19 
  1694. .LP
  1695.     2.4
  1696.      Terminal adaption functions for DTEs conforming to X.1 user class of 
  1697. service 1 and 2 
  1698. .sp 1P
  1699. .LP
  1700. 3
  1701.     \fITest loops\fR 
  1702. .sp 9p
  1703. .RT
  1704. .sp 1P
  1705. .LP
  1706. \fIAnnex\ A\fR     \(em
  1707.     SDL diagrams
  1708. .sp 9p
  1709. .RT
  1710. .sp 1P
  1711. .LP
  1712. \fIAppendix\ I\fR     \(em
  1713.     Universal terminal adaptor
  1714. .sp 9p
  1715. .RT
  1716. .sp 1P
  1717. .LP
  1718. \fIAppendix\ II\fR     \(em
  1719.     Inslot identification of intermediate bit rate
  1720. .sp 9p
  1721. .RT
  1722. .sp 2P
  1723. .LP
  1724. \fB1\fR     \fBReference configurations\fR 
  1725. .sp 1P
  1726. .RT
  1727. .PP
  1728. Figures 1\(hy1/X.30 and 1\(hy2/X.30 show examples of possible
  1729. configurations and are included simply as an aid to \(sc\ 2 describing the
  1730. TA functions.
  1731. .RT
  1732. .sp 1P
  1733. .LP
  1734. 1.1
  1735.     \fICustomer access configuration\fR 
  1736. .sp 9p
  1737. .RT
  1738. .PP
  1739. For the connection of X.21, X.21\|\fIbis\fR \| or X.20\|\fIbis\fR \| based 
  1740. DTEs to the ISDN, Figure\ 1\(hy1/X.30 shows a possible reference 
  1741. configuration.
  1742. .RT
  1743. .sp 1P
  1744. .LP
  1745. 1.2
  1746.     \fINetwork configuration\fR 
  1747. .sp 9p
  1748. .RT
  1749. .PP
  1750. The specification of terminal adaption functions takes account of the network 
  1751. configuration and the end\(hyto\(hyend connection types shown in 
  1752. Figure\ 1\(hy2/X.30 in which the associated terminal equipment TE1 and 
  1753. TE2 may be involved. 
  1754. .PP
  1755. The TA functions for this scenario are described in \(sc\ 2.
  1756. .bp
  1757. .RT
  1758. .LP
  1759. .rs
  1760. .sp 22P
  1761. .ad r
  1762. \fBFigure 1\(hy1/X.30, (N), p.\fR 
  1763. .sp 1P
  1764. .RT
  1765. .ad b
  1766. .RT
  1767. .LP
  1768. .rs
  1769. .sp 25P
  1770. .ad r
  1771. \fBFigure 1\(hy2/X.30, (N), p.\fR 
  1772. .sp 1P
  1773. .RT
  1774. .ad b
  1775. .RT
  1776. .LP
  1777. .bp
  1778. .PP
  1779. The terminals TE1 and TE2 are physically and logically connected to the 
  1780. ISDN where the call is handled. 
  1781. .PP
  1782. The TA performs the necessary rate adaption, the signalling conversion 
  1783. from the X.21 signalling to the Q.931 signalling and vice\(hyversa (X.21 
  1784. mapping) and ready for data alignment. Interworking with dedicated networks, 
  1785. e.g.\ a 
  1786. CSPDN, will be provided on the basis of trunk lines interconnection by using
  1787. Interworking Functions (IWF).
  1788. .PP
  1789. The following principles shall apply:
  1790. .RT
  1791. .LP
  1792.     i)
  1793.      The non\(hyvoice services within the ISDN should basically not diverge 
  1794. from what is being developed in X\ Series Recommendations. This refers 
  1795. to the various aspects concerning quality of service, user facilities, 
  1796. call 
  1797. progress signals (see the X\ Series Recommendations, e.g.,\ X.2 and\ X.96).
  1798. However, existing features would be enhanced and additional features would 
  1799. also be developed if account were taken of the new ISDN customer capabilities 
  1800. (e.g.,\ multi\(hyterminal arrangement, user rate at 64\ kbit/s simultaneous
  1801. multi\(hymedia access as well as the possible solution of compatibility
  1802. checking).
  1803. .LP
  1804.     ii)
  1805.     Integration of X.21 based services into the ISDN is
  1806. applicable to user classes of services\ 3 to\ 7, and\ 19. Integration of
  1807. X.20\|\fIbis\fR based services into the ISDN is applicable to user classes of
  1808. service\ 1 and\ 2.
  1809. .LP
  1810.     iii)
  1811.     Terminals TE1 and TE2 connected to an ISDN shall use
  1812. the ISDN numbering scheme (see Recommendation\ E.164).
  1813. .sp 1P
  1814. .LP
  1815. 1.3
  1816.     \fIInterworking situation\fR 
  1817. .sp 9p
  1818. .RT
  1819. .PP
  1820. Bearing in mind that this Recommendation defines the functions
  1821. performed by the X.21 terminal adaptors (TA\ X.21) and X.21\|\fIbis\fR terminal
  1822. adaptors (TA X.20\|\fIbis\fR ) and X.20\|\fIbis\fR terminal adaptors (TA\ 
  1823. X.20\|\fIbis\fR ), the following cases of interworking between these terminal 
  1824. adaptors and DTEs 
  1825. connected to CSPDN and PSTN may appear:
  1826. .RT
  1827. .LP
  1828.     a)
  1829.     For user classes of service 3 to 7:
  1830. .LP
  1831.     (1)\ TA X.21\ \(hy\|\(hy\|\(hy\ TA X.21
  1832. .LP
  1833.     (2)\ TA X.21\ \(hy\|\(hy\|\(hy\ TA X.21\|\fIbis\fR 
  1834. .LP
  1835.     (3)\ TA X.21\ \fIbis\fR \ \(hy\|\(hy\|\(hy\ TA X.21\|\fIbis\fR 
  1836. .LP
  1837.     (4)\ TA X.21\ \(hy\|\(hy\|\(hy\ DTE X.21
  1838. .LP
  1839.     (5)\ TA X.21\ \(hy\|\(hy\|\(hy\ DTE X.21\|\fIbis\fR 
  1840. .LP
  1841.     (6)\ TA X.21\ \(hy\|\(hy\|\(hy\ V series DTE
  1842. .LP
  1843.     (7)\ TA X.21\ \fIbis\fR \ \(hy\|\(hy\|\(hy\ DTE X.21
  1844. .LP
  1845.     (8)\ TA X.21\ \fIbis\fR \ \(hy\|\(hy\|\(hy\ DTE X.21\|\fIbis\fR 
  1846. .LP
  1847.     (9)\ TA X.21\ \fIbis\fR \ \(hy\|\(hy\|\(hy\ V series DTE
  1848. .LP
  1849.     b)
  1850.     For user class of service 19:
  1851. .LP
  1852.     (10)\ TA X.21\ \(hy\|\(hy\|\(hy\ TA X.21
  1853. .LP
  1854.     (11)\ TA X.21\ \(hy\|\(hy\|\(hy\ TA X.21\|\fIbis\fR 
  1855. .LP
  1856.     (12)\ TA X.21\ \fIbis\fR \ \(hy\|\(hy\|\(hy\ TA X.21\|\fIbis\fR 
  1857. .LP
  1858.     (13)\ TA X.21\ \(hy\|\(hy\|\(hy\ TE1 (S/T reference point)
  1859. .LP
  1860.     (14)\ TA X.21\ \fIbis\fR \ \(hy\|\(hy\|\(hy\ TE1 (S/T reference
  1861. point)
  1862. .LP
  1863.     c)
  1864.     For user classes of service 1 and 2:
  1865. .LP
  1866.     (15)\ TA X.20\ \fIbis\fR \ \(hy\|\(hy\|\(hy\ TA X.20\|\fIbis\fR 
  1867. .LP
  1868.     (16)\ TA X.20\ \fIbis\fR \ \(hy\|\(hy\|\(hy\ DTE X.20\|\fIbis\fR 
  1869. .LP
  1870.     (17)\ TA X.20\ \fIbis\fR \ \(hy\|\(hy\|\(hy\ V series DTE
  1871. .PP
  1872. \fINote\ 1\fR \ \(em\ This Recommendation is intended to cover all
  1873. TA\(hyfunctions necessary to allow interworking as listed above. Currently, 
  1874. this Recommendation covers all TA\(hyfunctions necessary to allow interworking 
  1875. between DTEs connected to ISDN and to CSPDN with the following exceptions: 
  1876. .LP
  1877.     1)
  1878.     for X.21\|\fIbis\fR \| and X.20\|\fIbis\fR \| only, the call control
  1879. procedure with direct call has been explicitly covered, but
  1880. other interface arrangements of X.21\|\fIbis\fR and X.20\|\fIbis\fR are not
  1881. precluded;
  1882. .LP
  1883.     2)
  1884.     for X.21\|\fIbis\fR , the half\(hyduplex mode of operation is for
  1885. further study.
  1886. .bp
  1887. .PP
  1888. This applies to all the cases listed above, where at least one
  1889. X.21\|\fIbis\fR \| or X.20\|\fIbis\fR \| terminal is involved. Alignment 
  1890. with the 
  1891. interworking functions may be necessary when the relevant Recommendations 
  1892. are available. 
  1893. .PP
  1894. \fINote\ 2\fR \ \(em\ Within the interworking cases 1\(hy17 mentioned above, 
  1895. the 
  1896. functions provided by TA\ X.21\|\fIbis\fR , TA\ X.20\|\fIbis\fR and the 
  1897. functions provided by TA\ V.110 should be compatible. 
  1898. .RT
  1899. .sp 2P
  1900. .LP
  1901. \fB2\fR     \fBTerminal adaption functions\fR 
  1902. .sp 1P
  1903. .RT
  1904. .PP
  1905. The terminal adaption functions to support X.21, X.21\|\fIbis\fR \| and/or 
  1906. X.20\|\fIbis\fR \| based DTEs can be subdivided into three areas, namely: 
  1907. .RT
  1908. .LP
  1909.     \(em
  1910.     rate adaption functions;
  1911. .LP
  1912.     \(em
  1913.     X.21/Q.931 mapping functions for call control;
  1914. .LP
  1915.     \(em
  1916.     ready for data alignment.
  1917. .PP
  1918. Some Administrations may provide separate TAs either for each
  1919. Recommendation\ X.1 user class of service or for a group of user classes of
  1920. service. Other Administrations may provide a universal TA for all user
  1921. classes of service\ 3 to\ 7 or\ 19 or\ 1 and\ 2. Within the Recommendation only
  1922. such functions are described which refer to single rate TAs. Additional
  1923. functions necessary for universal TAs (e.g.\ user rate identification) are
  1924. outlined in Appendix\ I.
  1925. .LP
  1926. 2.1
  1927.     \fITerminal adaption functions for DTEs conforming to X.1\fR 
  1928. \fIuser\fR \fIclasses of service\fR \fI3 to\ 6\fR 
  1929. .sp 1P
  1930. .RT
  1931. .sp 2P
  1932. .LP
  1933. 2.1.1
  1934.     \fIRate adaption\fR \fIfunctions\fR 
  1935. .sp 1P
  1936. .RT
  1937. .sp 1P
  1938. .LP
  1939. 2.1.1.1
  1940.     \fIGeneral approach\fR 
  1941. .sp 9p
  1942. .RT
  1943. .PP
  1944. The rate adaption functions within the TA are shown in
  1945. Figure\ 2\(hy1/X.30. The function RA1 adapts the X.1 user rate to the next 
  1946. higher rate expressed by 2\fI\fI 
  1947. \u\fIk\fR\dtimes 8\ kbit/s (where \fIk\fR \ =\ 0 or\ 1). RA2 performs a 
  1948. second conversion to 64\ kbit/s. 
  1949. .RT
  1950. .LP
  1951. .rs
  1952. .sp 11P
  1953. .ad r
  1954. \fBFigure 2\(hy1/X.30, (M), p.\fR 
  1955. .sp 1P
  1956. .RT
  1957. .ad b
  1958. .RT
  1959. .sp 2P
  1960. .LP
  1961. 2.1.1.2
  1962.     \fIFirst step of\fR 
  1963. \fIrate adaption\fR \fI(RA1) of X.1 rates to\fR \fI\fIthe intermediate 
  1964. rates of 8/16\ kbit/s\fR 
  1965. .sp 1P
  1966. .RT
  1967. .sp 1P
  1968. .LP
  1969. 2.1.1.2.1
  1970.     \fIFrame structure\fR 
  1971. .sp 9p
  1972. .RT
  1973. .PP
  1974. The conversion of the X.1 rates for user classes 3, 4 and 5 to
  1975. 8\ kbit/s, and for user class of service\ 6 to 16\ kbit/s, shall be implemented 
  1976. by means of the 40\ bit frame structure shown in Figure\ 2\(hy2/X.30. 
  1977. .bp
  1978. .RT
  1979. .LP
  1980. .rs
  1981. .sp 20P
  1982. .ad r
  1983. \fBFigure 2\(hy2/X.30 (comme tableau) [T1.30], p.\fR 
  1984. .sp 1P
  1985. .RT
  1986. .ad b
  1987. .RT
  1988. .PP
  1989. Figure 2\(hy2/X.30 shows that, in addition to the basic frame, a two frame 
  1990. multiframe is employed. In odd frames, octet\ 0 contains all zeros, whilst 
  1991. in even frames octet\ 0 consists of a one followed by seven E\ bits (see 
  1992. \(sc\ 2.1.1.2.4). The order of bit transmission of the 40\ bit frame is from
  1993. left\(hyto\(hyright and from top\(hyto\(hybottom.
  1994. .sp 1P
  1995. .LP
  1996. 2.1.1.2.2
  1997.     \fIFrame synchronization\fR 
  1998. .sp 9p
  1999. .RT
  2000. .PP
  2001. The 17 bit frame alignment pattern consists of all 8 bits (set to zero) 
  2002. of octet\ 0 in odd frames and bit\ 1 (set to\ 1) of the following 
  2003. consecutive 9\ octets of the 80\ bit long multiframe (see also \(sc\ 2.1.1.4.2). 
  2004. The first bit of octet\ 0 alternates between one and zero in consecutive 
  2005. frames and therefore provides a multiframe synchronization bit. 
  2006. .RT
  2007. .sp 1P
  2008. .LP
  2009. 2.1.1.2.3
  2010.     \fIStatus bits\fR \fISP, SQ, SR\fR 
  2011. .sp 9p
  2012. .RT
  2013. .PP
  2014. The bits SP, SQ and SR are used to convey channel associated status information. 
  2015. The mapping of the information on circuit C of the\ X.21 interface to the 
  2016. S bits and the circuit\ I in the distant interface should be done in such 
  2017. a way that the SP, SQ and SR bits are associated with the bit groups P, 
  2018. Q 
  2019. and\ R. To assure proper and secure operation the mapping scheme has to be
  2020. consistent with Recommendations\ X.21 and\ X.24.
  2021. .PP
  2022. The mechanism for mapping is as follows:
  2023. .RT
  2024. .LP
  2025.     \(em
  2026.     In all cases where X.21 byte timing interchange circuit B is
  2027. not provided, the status bits SP, SQ and SR of the bit groups P,
  2028. Q and R are evaluated by sampling the C\ lead in the middle of
  2029. the 8th\ bit of the respective preceding bit group. On the other
  2030. hand, the conditions of the status bits SP, SQ and SR are
  2031. adopted by the I\ lead beginning with the transition of the
  2032. respective 8th\ bit of a bit group\ R, P and Q to the 1st\ bit of
  2033. the consecutive bit group\ P,Q and R on the R\ lead (see
  2034. Figure\ 2\(hy3/X.30).
  2035. .LP
  2036.     \(em
  2037.     In the case where X.21\(hybyte timing interchange circuit B is
  2038. provided for character alignment, circuit\ C is sampled
  2039. together with the bit\ 8 of the preceding character and
  2040. circuit\ I is changing its state at the boundaries between old
  2041. and new characters at circuit\ R. This operation is defined
  2042. in Recommendation\ X.24.
  2043. .bp
  2044. .LP
  2045. .rs
  2046. .sp 47P
  2047. .ad r
  2048. \fBFigure 2\(hy3/X.30, (MC), p.\fR 
  2049. .sp 1P
  2050. .RT
  2051. .ad b
  2052. .RT
  2053. .LP
  2054. .bp
  2055. .PP
  2056. \fINote\ 1\fR \ \(em\ According to Recommendation X.21 the provision of 
  2057. the byte timing interchange circuit\ B is not mandatory. 
  2058. .PP
  2059. \fINote\ 2\fR \ \(em\ The status bits may be used to transfer, during the data
  2060. transfer phase, information for half\(hyduplex operation between TA\ X.21\|\fIbis\fR 
  2061. and TA\ X.21 or TA\ X.21\|\fIbis\fR (i.e.\ mapping of the condition of 
  2062. the C\ lead of the 
  2063. TA\ X.21, of the 105\ lead of the TA\ X.21\|\fIbis\fR , to the condition 
  2064. on the 109\ lead of the remote TA\ X.21\|\fIbis\fR , and mapping of the 
  2065. condition of the 105\ lead of 
  2066. the TA\ X.21\ \fIbis\fR to the condition of the I\ lead on the remote TA\ 
  2067. X.21). 
  2068. .PP
  2069. \fINote\ 3\fR \ \(em\ For bits SP, SQ, SR and X, a ZERO corresponds to the ON
  2070. condition, a ONE to the OFF condition.
  2071. .RT
  2072. .sp 1P
  2073. .LP
  2074. 2.1.1.2.4
  2075.     \fIAdditional signalling capacity\fR 
  2076. (E bits)
  2077. .sp 9p
  2078. .RT
  2079. .PP
  2080. The E bits provide the additional signalling capacity for the
  2081. conveyance of information relating to the user rate. The coding of these 
  2082. bits is shown in Table\ 2\(hy1/X.30. 
  2083. .RT
  2084. .LP
  2085. .sp 1
  2086. .ce
  2087. \fBH.T. [T2.30]\fR 
  2088. .ce
  2089. TABLE\ 2\(hy1/X.30
  2090. .ps 9
  2091. .vs 11
  2092. .nr VS 11
  2093. .nr PS 9
  2094. .TS
  2095. center box;
  2096. lw(66p) | lw(18p) | lw(18p) | lw(18p) | lw(18p) | lw(18p) | lw(18p) | lw(54p) .
  2097.                             
  2098. .TE
  2099. .nr PS 9
  2100. .RT
  2101. .ad r
  2102. \fBTable 2\(hy1/X.30 [T2.30], p.\fR 
  2103. .sp 1P
  2104. .RT
  2105. .ad b
  2106. .RT
  2107. .LP
  2108. .sp 1
  2109. .sp 1P
  2110. .LP
  2111. 2.1.1.2.5
  2112.     \fIData bits\fR 
  2113. .sp 9p
  2114. .RT
  2115. .PP
  2116. Data is conveyed in P, Q and R bits, i.e. 24 bits per
  2117. frame.
  2118. .RT
  2119. .sp 1P
  2120. .LP
  2121. 2.1.1.2.6
  2122.     \fIRepetition strategy\fR 
  2123. .sp 9p
  2124. .RT
  2125. .PP
  2126. For the adaption of user rates 600, 2400, 4800 bit/s to the
  2127. 8\ kbit/s intermediate rate and of the 9600\ bit/s user rate to the 16\ kbit/s
  2128. intermediate rate, the sequence of even and odd octet\ 0 shall be maintained 
  2129. as defined in Figure\ 2\(hy4/X.30. In order to achieve both short frame 
  2130. synchronization as well as short transfer delay times, a user\(hybit\(hyrepetition 
  2131. method is proposed. Figures 2\(hy4a/X.30 and\ 2.4b/X.30 contain a scheme 
  2132. for the 
  2133. adaption of the 600\ bit/s user rate and of the 2400\ bit/s user rate
  2134. respectively into the 8\ kbit/s bearer rate. Figures\ 2\(hy4c/X.30 and\ 
  2135. 2\(hy4d/X.30 
  2136. show the adaption of the 4800\ bit/s user rate to the 8\ kbit/s bearer 
  2137. rate and of the 9600\ bit/s user rate to the 16\ kbit/s bearer rate. 
  2138. .bp
  2139. .PP
  2140. In the case of a 600 bit/s user rate, an explicit frame group
  2141. synchronization pattern using bit E7 is provided to ensure preservation of
  2142. user octet boundaries and associated status bit. The coding for the E7 bit
  2143. shall be as follows:
  2144. \v'6p'
  2145. .RT
  2146. .sp 1P
  2147. .ce 1000
  2148. .\|.\|.\ 1110111011101\ .\|.\|.
  2149. .ce 0
  2150. .sp 1P
  2151. .LP
  2152. .sp 1
  2153. where the value 0 is marking the last 40 bit frame of each 8\ \(mu\ 40\ 
  2154. bit frame 
  2155. group which contains three integer user octets.
  2156. .LP
  2157. .sp 1
  2158. .rs
  2159. .sp 39P
  2160. .ad r
  2161. \fBFigures 2.4a\(hyd/X.30 (comme tableau) [T3.30], p.\fR 
  2162. .sp 1P
  2163. .RT
  2164. .ad b
  2165. .RT
  2166. .LP
  2167. .bp
  2168. .sp 1P
  2169. .LP
  2170. 2.1.1.3
  2171.     \fISecond step of\fR 
  2172. \fIrate adaption\fR \fI(RA2)\fR 
  2173. .sp 9p
  2174. .RT
  2175. .PP
  2176. As rate adaption of a single substream (8/16\ kbit/s) to 64\ kbit/s and 
  2177. multiplexing of several substreams to 64\ kbit/s have to be compatible 
  2178. to 
  2179. enable interworking, a common approach is needed for second step rate adaption 
  2180. and for subchannel multiplexing. It is described in 
  2181. Recommendation\ I.460.
  2182. .RT
  2183. .sp 1P
  2184. .LP
  2185. 2.1.1.4
  2186.     \fIFraming/reframing method\fR \fIand\fR 
  2187. \fIuser rate\fR 
  2188. \fIidentification\fR 
  2189. .sp 9p
  2190. .RT
  2191. .PP
  2192. For framing/reframing and user rate identification the following
  2193. strategies shall be applied.
  2194. .RT
  2195. .sp 1P
  2196. .LP
  2197. 2.1.1.4.1
  2198.     \fISearch for frame alignment\fR 
  2199. .sp 9p
  2200. .RT
  2201. .PP
  2202. The following 17 bit alignment pattern is searched for:
  2203. .RT
  2204. .LP
  2205.     0
  2206.     0
  2207.     0
  2208.     0
  2209.     0
  2210.     0
  2211.     0
  2212.     0
  2213.     1XXXXXXX
  2214.     1XXXXXXX
  2215.     1XXXXXXX
  2216.     1XXXXXXX
  2217.     1
  2218.     X
  2219.     X
  2220.     X
  2221.     X
  2222.     X
  2223.     X
  2224.     X
  2225.     1XXXXXXX
  2226.     1XXXXXXX
  2227.     1XXXXXXX
  2228.     1XXXXXXX
  2229. .PP
  2230. No errors shall be tolerated in the defined bit positions
  2231. (i.e.\ all bit positions excluding those denoted 
  2232. by\ \*QX\*U).
  2233. .PP
  2234. It is assumed that the error rate will be sufficiently low to expect alignment 
  2235. following the detection of one 80\ bit multiframe. 
  2236. .PP
  2237. In the case of X.1 user class of service 3 (600\ bit/s), a further
  2238. search for the frame group synchronization pattern contained in bit position 
  2239. E7 shall be performed. 
  2240. .RT
  2241. .sp 1P
  2242. .LP
  2243. 2.1.1.4.2
  2244.     \fIAlignment monitoring/recovery\fR 
  2245. .sp 9p
  2246. .RT
  2247. .PP
  2248. The monitoring of the alignment shall be a continuous
  2249. process. The alignment is assumed to be correct if there is no error in 
  2250. the 17 bit alignment pattern of the 80\ bit multiframe. 
  2251. .PP
  2252. Loss of alignment is assumed following the detection of N
  2253. (provisional value:\ 3) consecutive multiframes each with at least one 
  2254. alignment bit error. 
  2255. .PP
  2256. Following a loss of alignment the TA shall enter a recovery state,
  2257. which
  2258. is indicated at the X.21 interface by r\ =\ 1 and i\ =\ ON. In the transmitted
  2259. frame, bit\ X, if used for the indication of the frame synchronizion to 
  2260. the far end, shall be set to OFF. 
  2261. .PP
  2262. If the recovery of alignment is achieved, r and i present again the data 
  2263. and the status information respectively from the received frames. Bit\ 
  2264. X in the transmitted frames must be in the ON condition. 
  2265. .PP
  2266. If recovery of alignment is not achieved within a fixed period, the TA 
  2267. shall indicate \*QDCE not ready\*U (state\ 22) by signalling r\ =\ 0, i\ 
  2268. =\ OFF. The 
  2269. duration of this period is network dependent (as in Recommendation\ X.21,
  2270. \(sc\ 2.6.2). In case of a circuit\(hyswitched service this leads to a 
  2271. clearing of the connection. 
  2272. .PP
  2273. In the case of a X.21\|\fIbis\fR \| TA, the signalling procedure in
  2274. Recommendation\ V.110, \(sc\ 4.1.5 should be used at the R\(hyreference
  2275. point.
  2276. .RT
  2277. .sp 1P
  2278. .LP
  2279. 2.1.1.4.3
  2280.     \fIIdentification of intermediate bit rate\fR 
  2281. .sp 9p
  2282. .RT
  2283. .PP
  2284. As a basic approach the intermediate bit rate is derived from the X.1 user 
  2285. rate contained in the Q.931 SETUP message. 
  2286. .PP
  2287. As an alternative solution the intermediate bit rate may optionally be 
  2288. identified by relying solely on B\(hychannel information 
  2289. (see Appendix\ II).
  2290. .RT
  2291. .sp 1P
  2292. .LP
  2293. 2.1.2
  2294.     \fIX.21/X.21\|bis to Q.931 protocol mapping\fR 
  2295. .sp 9p
  2296. .RT
  2297. .PP
  2298. The D\(hychannel signalling capabilities of the ISDN\(hycustomer\(hyaccess 
  2299. as defined in Recommendation\ Q.931 have to include the requirements arising 
  2300. from the mapping of the X.21 and X.21\|\fIbis\fR interface signalling procedures 
  2301. to the Q.931 protocol at the S/T reference point. 
  2302. .PP
  2303. The logical representation of these mapping functions is shown in
  2304. Figure\ 2\(hy5/X.30.
  2305. .bp
  2306. .RT
  2307. .LP
  2308. .rs
  2309. .sp 16P
  2310. .ad r
  2311. \fBFigure 2\(hy5/X.30, (M), p.\fR 
  2312. .sp 1P
  2313. .RT
  2314. .ad b
  2315. .RT
  2316. .PP
  2317. The D\(hychannel signalling capabilities provided to X.21 and
  2318. X.21\|\fIbis\fR \| based terminals shall comprise the signalling messages 
  2319. as defined in Recommendation\ Q.931. 
  2320. .PP
  2321. The following description and drawings depict examples of X.21 and
  2322. X.21\|\fIbis\fR \| mapping to the ISDN call control procedures. It is recognized 
  2323. that other possibilities and user options exist but this section is intended 
  2324. to 
  2325. provide general guidelines on\ X.21 and\ X.21\|\fIbis\fR support. Only 
  2326. the normal call establishment and clearing procedures are shown. 
  2327. .PP
  2328. \fINote\ 1\fR \ \(em\ Annex A contains an SDL description of the mapping 
  2329. of the procedures at the R\(hyreference point to procedures at the S/T 
  2330. reference point 
  2331. and vice versa. However, the TA internal processes and states contained 
  2332. in the SDL diagrams are understood not to be binding for implementation. 
  2333. .PP
  2334. \fINote\ 2\fR \ \(em\ Manual direct or address calls and manual disconnection
  2335. from the TA should also be possible through the mapping of standard DTE/TA
  2336. interface procedures with manual operations at the TA. In addition, automatic 
  2337. address calls may also be possible by the DTE employing a V.25 interface 
  2338. between the DTE and TA (see Recommendation\ V.110).
  2339. .RT
  2340. .sp 1P
  2341. .LP
  2342. 2.1.2.1
  2343.     \fIQ.931/X.21\fR 
  2344. \fImapping\fR \| (see Figures 2\(hy6/X.30 and
  2345. 2\(hy7/X.30)
  2346. .sp 9p
  2347. .RT
  2348. .PP
  2349. The following sections are titled with the names of the Q.931
  2350. signalling messages at the S/T reference point.
  2351. .RT
  2352. .sp 1P
  2353. .LP
  2354. 2.1.2.1.1
  2355.     \fISETUP (from TA)\fR 
  2356. .sp 9p
  2357. .RT
  2358. .PP
  2359. In ready state (state\ 1) both DTE and TA transmit r\ =\ 1, i\ =\ OFF
  2360. via the X.21 interface.
  2361. .PP
  2362. When the calling DTE indicates a call request (state 2, r\ =\ 0, i\ =\ 
  2363. ON) at the X.21 interface, the TA transmits a proceed to select signal 
  2364. to the DTE (state\ 3, +,\ OFF). The DTE begins to send selection signals 
  2365. to the TA 
  2366. (state\ 4, r\ =\ +, i\ =\ OFF).
  2367. .PP
  2368. When an end of selection signal (r\ =\ +, i\ =\ ON) is received at the
  2369. X.21 interface, the TA transmits a SETUP message via the D\(hychannel at 
  2370. the S/T reference point. 
  2371. .PP
  2372. The Bearer capability information element included in the SETUP
  2373. message shall be coded with:
  2374. .RT
  2375. .LP
  2376.     \(em
  2377.     information transfer capability set to either:
  2378. .LP
  2379.     a)
  2380.     \*Qunrestricted digital information\*U, or
  2381. .LP
  2382.     b)
  2383.     \*Qrestricted digital information\*U;
  2384. .LP
  2385.     \(em
  2386.     transfer mode set to \*Qcircuit mode\*U;
  2387. .LP
  2388.     \(em
  2389.     information transfer rate set to \*Q64 kbit/s\*U.
  2390. .bp
  2391. .PP
  2392. \fINote\fR \ \(em\ Bearer capability information element octets 4a and 4b
  2393. shall not be included.
  2394. .PP
  2395. The user may also specify the layer\ 1 (e.g. rate adaption), layer 2
  2396. (e.g.\ LAPB) and layer\ 3 (e.g.\ X.25) information transfer protocols in 
  2397. the Low layer compatibility information element in the SETUP message. (See 
  2398. Q.931, annex entitled, \*QLow layer information coding principles\*U). 
  2399. .PP
  2400. The Called party address information element shall be encoded en\(hybloc 
  2401. i.e.,\ with the complete address of the called party as received from the 
  2402. X.21 interface. 
  2403. .PP
  2404. Afterwards, the state DCE waiting (state 6A, r = SYN, i = OFF) is
  2405. entered at the X.21 interface.
  2406. .RT
  2407. .sp 1P
  2408. .LP
  2409. 2.1.2.1.2
  2410.     \fISETUP ACKNOWLEDGE/CALL PROCEEDING (from ET)\fR 
  2411. .sp 9p
  2412. .RT
  2413. .PP
  2414. The network reaction on the SETUP message received from the TA can  be either:
  2415. .RT
  2416. .LP
  2417.     a)
  2418.     sending of a CALL PROCEEDING message to the TA; when the
  2419. CALL PROCEEDING message is received on the D\(hychannel at the
  2420. S/T reference point, the B\(hychannel will be allocated and the
  2421. TA transmits r\ =\ 1, i\ =\ OFF (within 80\ bit multiframes in the
  2422. case of user classes\ 3\(hy6) via the B\(hychannel at the S/T
  2423. reference point; or
  2424. .LP
  2425.     b)
  2426.     sending of a SETUP ACKNOWLEDGE message to the TA; when the
  2427. SETUP ACKNOWLEDGE message is received on the D\(hychannel at the
  2428. S/T reference point, the B\(hychannel will be allocated and
  2429. and the TA transmits 1, OFF (within 80\ bit multiframes in the
  2430. case of user classes\ 3\(hy6) via the B\ channel at the S/T
  2431. reference point.
  2432. .LP
  2433.     In this case subsequent reception of CALL PROCEEDING does
  2434. not entail any further actions in the\ TA.
  2435. .sp 1P
  2436. .LP
  2437. 2.1.2.1.3
  2438.     \fIALERTING (from ET)\fR 
  2439. .sp 9p
  2440. .RT
  2441. .PP
  2442. ALERTING message is only used with manual answering.
  2443. .PP
  2444. When an ALERTING message is received on the D\(hychannel at the
  2445. S/T reference point, the TA transmits the call progress signal (state\ 7,
  2446. r\ =\ IA5,\ i\ =\ OFF) to the calling DTE.
  2447. .PP
  2448. Afterwards the state DCE waiting (state 6A, r\ =\ SYN, i\ =\ OFF) is
  2449. entered at the X.21 interface.
  2450. .RT
  2451. .sp 1P
  2452. .LP
  2453. 2.1.2.1.4
  2454.     \fICONNECT (from ET)\fR 
  2455. .sp 9p
  2456. .RT
  2457. .PP
  2458. When a CONNECT is received on the D\(hychannel at the S/T reference
  2459. point, the TA transmits any DCE provided information (state\ 10, r\ =\ IA5,
  2460. i\ =\ OFF) to the calling DTE. Afterwards the state connection in progress
  2461. (state\ 11) is entered at the X.21 interface.
  2462. .PP
  2463. When the frame alignment pattern of the 80 bit multiframe (in the case 
  2464. of Recommendation\ X.1 user classes\ 3\(hy6) is received on the B\(hychannel 
  2465. at the 
  2466. S/T reference point, the TA performs switch\(hythrough.
  2467. .PP
  2468. When the calling DTE receives (1,\ ON) via the through\(hyconnected
  2469. B\(hychannel at the X.21 interface, the calling DTE enters the state ready for
  2470. data (state\ 12) and data transfer (state\ 13) can begin.
  2471. .RT
  2472. .sp 1P
  2473. .LP
  2474. 2.1.2.1.5
  2475.     \fISETUP (from ET)\fR 
  2476. .sp 9p
  2477. .RT
  2478. .PP
  2479. The TA shall not accept a SETUP message unless the X.21 interface is in 
  2480. the ready state (state\ 1). When a SETUP message is received on the 
  2481. D\(hychannel at the S/T reference point, the TA shall follow the procedures for
  2482. determining compatibility checking (e.g.,\ data signalling rate) found in
  2483. Recommendation\ Q.931. If the TA determines that it can respond to the 
  2484. incoming call, it follows the procedures of Recommendation\ Q.931. It is 
  2485. expected that 
  2486. ALERTING message would only be used with terminals that answer manually.
  2487. .PP
  2488. The TA transmits an incoming call (r\ =\ Bell, i\ =\ OFF) via the X.21
  2489. interface to the called DTE, and the incoming call state (state\ 8, r\ =\ BEL,
  2490. i\ =\ OFF) entered.
  2491. .PP
  2492. Call offering procedure in a multiterminal configuration is described in 
  2493. \(sc\ 2.1.3. 
  2494. .RT
  2495. .sp 1P
  2496. .LP
  2497. 2.1.2.1.6
  2498.     \fICONNECT (from TA)\fR 
  2499. .sp 9p
  2500. .RT
  2501. .PP
  2502. When a call accepted (state 9, t\ =\ 1, c\ =\ ON) is received from
  2503. the called DTE, the TA transmits a CONNECT message via the D\(hychannel of the
  2504. S\(hyinterface.
  2505. .bp
  2506. .RT
  2507. .sp 1P
  2508. .LP
  2509. 2.1.2.1.7
  2510.     \fICONNECT ACKNOWLEDGE (from ET)\fR 
  2511. .sp 9p
  2512. .RT
  2513. .PP
  2514. When a CONNECT ACKNOWLEDGE message is received on the D\(hychannel at the 
  2515. reference point, the TA, selected by this message, transmits 1/OFF via 
  2516. the allocated B\(hychannel and signals connection in progress (state\ 11, 
  2517. r\ =\ 1, 
  2518. i\ =\ OFF) to the DTE after delivering DCE provided information if any.
  2519. .PP
  2520. The TA performs switch\(hythrough after the frame alignment pattern
  2521. (80\ bit multiframe in the case of user classes\ 3\(hy6) has been received 
  2522. via the B\(hychannel at the S/T reference point. 
  2523. .PP
  2524. When the called DTE receives 1, ON via the switched through B\(hychannel 
  2525. on the X.21 interface, the ready for data state (state\ 12, r\ =\ 1, i\ 
  2526. =\ ON) is 
  2527. entered and data transfer (state\ 13, r\ =\ D, i\ =\ ON) can begin.
  2528. .RT
  2529. .sp 1P
  2530. .LP
  2531. 2.1.2.1.8
  2532.     \fIRELEASE (from ET)\fR 
  2533. .sp 9p
  2534. .RT
  2535. .PP
  2536. In the case of a multiterminal configuration, the exchange
  2537. termination sends a RELEASE message to each TA that had signalled CALL
  2538. PROCEEDING, ALERTING or CONNECT but which was not selected for the call.
  2539. Subsequently the TA performs the DCE clear indication procedure at the X.21
  2540. interface and sends a RELEASE COMPLETE message to the exchange.
  2541. .RT
  2542. .sp 1P
  2543. .LP
  2544. 2.1.2.1.9
  2545.     \fIDISCONNECT (from TA)\fR 
  2546. .sp 9p
  2547. .RT
  2548. .PP
  2549. A DTE clear request (state 16, t = 0, c = OFF) is transmitted via the B\(hychannel 
  2550. from the clearing to the cleared DTE. 
  2551. .PP
  2552. The TA at the clearing DTE recognizes the state 16 at the
  2553. X.21\(hyinterface, separates the R\(hy and I\(hyleads from the B\(hychannel 
  2554. and transmits a DCE clear confirmation (state\ 17\ =\ 0, OFF) to the clearing 
  2555. DTE. It transmits 
  2556. also a DISCONNECT message via the D\(hychannel of the S/T reference point (see
  2557. Figure\ 2\(hy6/X.30).
  2558. .PP
  2559. After reception of the RELEASE message on the D\(hychannel, the TA tears 
  2560. down the B\(hychannel, sends RELEASE COMPLETE to the exchange, transmits 
  2561. DCE ready (r\ =\ 1, i\ =\ OFF) to the DTE, and the DTE enters the state 
  2562. DTE ready (state\ 1, t\ =\ 1, c\ =\ OFF). 
  2563. .RT
  2564. .sp 1P
  2565. .LP
  2566. 2.1.2.1.10\ \ \fIDISCONNECT (between TA)\fR 
  2567. .sp 9p
  2568. .RT
  2569. .PP
  2570. When the DTE initiates DTE clear request (t\ =\ 0,
  2571. c\ =\ OFF) this status is transmitted inslot within the B\(hychannel and 
  2572. received as DCE clear indication (r\ =\ 0, i\ =\ OFF) in the DTE (see 
  2573. Figure\ 2\(hy7/X.30).
  2574. .PP
  2575. The TA recognizes the clear request received inslot via the B\(hychannel 
  2576. at the S/T reference point, separates the R\(hy and I\(hyleads from the 
  2577. B\(hychannel and transmits a DCE clear indication (state\ 19\ =\ 0, OFF) 
  2578. to the DTE to be cleared. 
  2579. .PP
  2580. After the TA to be cleared has received DTE clear confirmation
  2581. (t\ =\ 0, c\ =\ OFF) from the DTE, it transmits the DISCONNECT message via the
  2582. D\(hychannel, and clears the B\(hychannel.
  2583. .PP
  2584. After reception of a RELEASE message on the D\(hychannel, the TA releases 
  2585. the call reference, sends RELEASE COMPLETE message to the exchange, transmits 
  2586. DCE ready (state\ 2, r\ =\ 1, i\ =\ OFF) to the DTE, and the DTE enters 
  2587. the state 
  2588. DTE ready (t\ =\ 1, c\ =\ OFF).
  2589. .RT
  2590. .LP
  2591. .rs
  2592. .sp 11P
  2593. .sp 2P
  2594. .LP
  2595. \fBMONTAGE : \(sc 2.1.2.1.11 SUR LE RESTE DE CETTE PAGE\fR 
  2596. .sp 1P
  2597. .RT
  2598. .LP
  2599. .bp
  2600.